Re: [Xenomai] problem gpio interrupts xenomai3 on the raspberry pi 2 (or 3)

[Nitin Kulkarni <nitink@kth.se>]

Hi Philippe,
>From your reply I guess its the same issue  with my SoC also. Do you think in my case the Intel joule pinctrl driver is not aware of Ipipe ?
Do you have any instances where an x86 based SoC was ported to solve this issue ?
Thanks for the info it explains a lot of things now.

- Nitin 

________________________________________
From: Xenomai <xenomai-bounces@xenomai.org> on behalf of xenomai-request@xenomai.org <xenomai-request@xenomai.org>
Sent: Tuesday, May 30, 2017 7:48 PM
To: xenomai@xenomai.org
Subject: Xenomai Digest, Vol 61, Issue 25

Send Xenomai mailing list submissions to
        xenomai@xenomai.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://xenomai.org/mailman/listinfo/xenomai
or, via email, send a message with subject or body 'help' to
        xenomai-request@xenomai.org

You can reach the person managing the list at
        xenomai-owner@xenomai.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xenomai digest..."


Today's Topics:

   1. Re: problem gpio interrupts xenomai3 on the raspberry pi 2
      (or 3) (Philippe Gerum)
   2. Re: problem gpio interrupts xenomai3 on the raspberry pi  2
      (or 3) (Nitin Kulkarni)


----------------------------------------------------------------------

Message: 1
Date: Tue, 30 May 2017 19:30:58 +0200
From: Philippe Gerum <rpm@xenomai.org>
To: Harco Kuppens <h.kuppens@cs.ru.nl>, xenomai@xenomai.org
Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the
        raspberry pi 2 (or 3)
Message-ID: <cb912c40-1247-6395-9a84-a3203dd5f022@xenomai.org>
Content-Type: text/plain; charset=utf-8

On 05/30/2017 06:38 PM, Harco Kuppens wrote:
> So I decided to also  test these wiringpi test programs on mine build
> xenomai 3 image for the rpi2. Unfortunately the isr.c wiringpi program
> didn't work anymore on mine build image. So even without using xenomai3,
> but just using linux the pi2 just hangs and a hard reset was needed.
>
> Thus I guess there is still something wrong with mine image?
> Does anybody know what I'm doing wrong?
> Or is this still a bug in the gpio library or in the patches applied?
>

It looks obvious that you tried hard and got your feet wet with Xenomai
already, so let's go straight to the point: the lockup issue when using
GPIO interrupts is most likely due to the I-pipe patch not properly
adapting the GPIO chip driver for dealing with IRQ virtualization.

In short, each IRQ controller which may be active on a SoC must be
driven by I-pipe aware code. For instance, the bcm2835 family has common
GPIOs controlled by the driver at drivers/pinctrl/pinctrl-bcm2835.c. If
that driver has not been patched specifically for supporting the IRQ
pipeline, then this won't work with Xenomai, and may well end up with
painful IRQ storms causing a machine hang. The same goes for any other
chip serving as an IRQ controller you might need on your platform.

So, first and foremost, I would recommend to make sure the I-pipe code
is right for your kernel, then build on top of that. A good way to
figure out which IRQ controllers are active is look at the output of
/proc/interrupts on a kernel that disables the interrupt pipeline.
Each IRQ information mentions the label of the controller which deals
with it. With that information, you need to cross-check whether the
corresponding IRQ chip driver (the one that bears this label in the
irq_chip descriptor structure) was made I-pipe aware.

Some time ago, I ported Xenomai 3 to the PI Zero (kernel 4.1.18), which
is based on the bcm2835 SoC like the PI 1 series. That code is available
from the vendors/raspberry/ipipe-4.1 branch at
git://git.xenomai.org/ipipe.git. This may be a good starting point, at
least for testing with a PI 1, before working on the required fixups for
supporting other Broadcom SoCs.

IIRC, RPI 2B and RPI 3 are based on the bcm2836, bcm2837 SoCs resp.,
which are not covered by the port just mentioned. You may find some
preliminary I-pipe related changes in the bcm2836 core interrupt support
code, but those have never been tested. By preliminary, I mean that
there is likely a few more IRQ controllers to make I-pipe aware on these
SoCs, aside of testing the initial changes.

Bottom line: using a stock I-pipe patch is unlikely to work out of the
box. The fact that such patch does support several SoCs equipped with
Cortex A7/A9 CPUs is by no mean a guarantee that all Cortex-based SoCs
are supported by the same code.

--
Philippe.



------------------------------

Message: 2
Date: Tue, 30 May 2017 17:47:58 +0000
From: Nitin Kulkarni <nitink@kth.se>
To: "xenomai@xenomai.org" <xenomai@xenomai.org>, "h.kuppens@cs.ru.nl"
        <h.kuppens@cs.ru.nl>
Subject: Re: [Xenomai] problem gpio interrupts xenomai3 on the
        raspberry pi    2 (or 3)
Message-ID: <1496166479457.35714@kth.se>
Content-Type: text/plain; charset="iso-8859-1"

Hi Harco,
Even I have a similar issue which I posted yesterday. Subject was "GPIO Interrupt is registered in Xenomai but handler is not
invoked when triggered". In my case I am not using an Intel Joule module.
I have searched a bit and I think its an issue with the ipipe patch and GPIO irq handling. My rtdm irq is registered and it shows in the /proc/xenomai/irq file but it is not triggered.

I am waiting for someone to reply, I am sure I missing something here or its an issue with few of the GPIO drivers not being aware of Ipipe.

@Others: If you have experienced similar issues please let me know.

-Nitin

________________________________________
From: Xenomai <xenomai-bounces@xenomai.org> on behalf of xenomai-request@xenomai.org <xenomai-request@xenomai.org>
Sent: Tuesday, May 30, 2017 6:38 PM
To: xenomai@xenomai.org
Subject: Xenomai Digest, Vol 61, Issue 24

Send Xenomai mailing list submissions to
        xenomai@xenomai.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://xenomai.org/mailman/listinfo/xenomai
or, via email, send a message with subject or body 'help' to
        xenomai-request@xenomai.org

You can reach the person managing the list at
        xenomai-owner@xenomai.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xenomai digest..."


Today's Topics:

   1. Re: dlopen failing when using shared library on xenomai 3.0.4
      (Fyleo)
   2. Re: dlopen failing when using shared library on xenomai 3.0.4
      (Fyleo)
   3. Re: dlopen failing when using shared library on xenomai 3.0.4
      (Philippe Gerum)
   4. vortex86dx (ali hagigat)
   5. Re: Problem with the T_LOCK (Philippe Gerum)
   6. problem gpio interrupts xenomai3 on the raspberry pi 2    (or 3)
      (Harco Kuppens)


----------------------------------------------------------------------

Message: 1
Date: Tue, 30 May 2017 12:17:59 +0200
From: Fyleo <fyleo45@gmail.com>
To: xenomai@xenomai.org
Subject: Re: [Xenomai] dlopen failing when using shared library on
        xenomai 3.0.4
Message-ID: <bbc4317c-2238-b9f1-0e4d-10a683618af8@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed


> Le 29/05/2017 ? 23:19, Fyleo a ?crit :
>> Hello all,
>>
>> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which
>> support only xenomai 2.6.4 for the moment.
>>
>> This software is design this way :
>>
>> A : main executable
>>
>> B : shared library abstracting thread API, with one library for
>> posix, for xenomai, ...
>>
>> The xenomai B library is linked against alchemy, copperplate, ...
>> (xeno-config --ldflags --auto-init-solib --skin=alchemy)
>>
>> The program works in a way that, at start time, it load with dlopen
>> the configured API (B).
>>
>> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the
>> error : "/usr/lib/libcopperplate.so.0: undefined symbol: main"
>>
>> Here is the simplified test case to reproduce the problem :
>>
>> main.c:
>>     #include <stdio.h>
>>     #include <stdlib.h>
>>     #include <dlfcn.h>
>>
>>     int main(int argc, char *const argv[])
>>     {
>>         void *handle;
>>
>>         handle = dlopen("./ulapi-xenomai.so", RTLD_GLOBAL|RTLD_NOW);
>>         if (!handle) {
>>             fprintf(stderr, "%s\n", dlerror());
>>             exit(EXIT_FAILURE);
>>         }
>>
>>         dlclose(handle);
>>         exit(EXIT_SUCCESS);
>>     }
>>
>> gcc main.c -o testcase -ldl
>> gcc -Wl,-soname,ulapi-xenomai.so -shared -o ulapi-xenomai.so
>> `xeno-config --ldflags --auto-init-solib --skin=alchemy`
>>
>> run testcase
>>
>> I am missing something or is there a solution that doesn't imply to
>> use RTLD_LAZY ?
>>
>> my xeno-config --info
>> Xenomai version: Xenomai/cobalt v3.0.4
>> Linux beaglebone 4.4.62-ti-xenomai-r105 #1 SMP Wed May 24 00:09:09
>> UTC 2017 armv7l GNU/Linux
>> Kernel parameters: console=ttyO0,115200n8
>> capemgr.disable_partno=BB-BONELT-HDMI
>> bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro
>> rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet
>> I-pipe release #7 detected
>> Cobalt core 3.0.4 detected
>> Compiler: gcc version 4.9.2 (Debian 4.9.2-10)
>> Build args: --prefix=/usr --includedir=/usr/include/xenomai
>> --mandir=/usr/share/man --with-testdir=/usr/lib/xenomai/testsuite
>> --enable-dlopen-libs --enable-smp --build arm-linux-gnueabihf
>> build_alias=arm-linux-gnueabihf
>>
>> Regards,
>>
>> Fyleo
>>
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> https://xenomai.org/mailman/listinfo/xenomai
On 30/05/2017 09:22, St?phane Ancelot wrote:
> Hi,
>
> Why don't you link the shared lib at compilation ?
>
> Regards,
> S.Ancelot
Hi,

Because there is multiple ulapi that can be loaded at execution time to
switch between posix (non-xenomai) thread, xenomai thread, rtai thread
and so on, depending on environnement variable.
It is not my program so i want to be less invasive as possible.

Regards,
Fyleo




------------------------------

Message: 2
Date: Tue, 30 May 2017 12:23:01 +0200
From: Fyleo <fyleo45@gmail.com>
To: Philippe Gerum <rpm@xenomai.org>, xenomai@xenomai.org
Subject: Re: [Xenomai] dlopen failing when using shared library on
        xenomai 3.0.4
Message-ID: <90600d56-7dfa-7726-f25b-d9301a915820@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 30/05/2017 09:12, Philippe Gerum wrote:
> On 05/29/2017 11:19 PM, Fyleo wrote:
>> Hello all,
>>
>> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which
>> support only xenomai 2.6.4 for the moment.
>>
>> This software is design this way :
>>
>> A : main executable
>>
>> B : shared library abstracting thread API, with one library for posix,
>> for xenomai, ...
>>
>> The xenomai B library is linked against alchemy, copperplate, ...
>> (xeno-config --ldflags --auto-init-solib --skin=alchemy)
>>
>> The program works in a way that, at start time, it load with dlopen the
>> configured API (B).
>>
>> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the error
>> : "/usr/lib/libcopperplate.so.0: undefined symbol: main"
>>
> Could you pick the change below and retry? Feedback welcome.
>
> http://git.xenomai.org/xenomai-3.git/commit/?id=48b2e57e29ca1c33eba14abb4b5eaa15431130fa
>
Hi,

This fix works, thanks.

But will it always work in executable auto init ? The symbol
"__real_main" have to be defined in user code if linked with bootstrap.o ?

Fyleo




------------------------------

Message: 3
Date: Tue, 30 May 2017 12:39:46 +0200
From: Philippe Gerum <rpm@xenomai.org>
To: Fyleo <fyleo45@gmail.com>, xenomai@xenomai.org
Subject: Re: [Xenomai] dlopen failing when using shared library on
        xenomai 3.0.4
Message-ID: <5f442ab6-0cf8-2c5d-bfca-53a0c2fa5ecd@xenomai.org>
Content-Type: text/plain; charset=utf-8

On 05/30/2017 12:23 PM, Fyleo wrote:
> On 30/05/2017 09:12, Philippe Gerum wrote:
>> On 05/29/2017 11:19 PM, Fyleo wrote:
>>> Hello all,
>>>
>>> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which
>>> support only xenomai 2.6.4 for the moment.
>>>
>>> This software is design this way :
>>>
>>> A : main executable
>>>
>>> B : shared library abstracting thread API, with one library for posix,
>>> for xenomai, ...
>>>
>>> The xenomai B library is linked against alchemy, copperplate, ...
>>> (xeno-config --ldflags --auto-init-solib --skin=alchemy)
>>>
>>> The program works in a way that, at start time, it load with dlopen the
>>> configured API (B).
>>>
>>> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the error
>>> : "/usr/lib/libcopperplate.so.0: undefined symbol: main"
>>>
>> Could you pick the change below and retry? Feedback welcome.
>>
>> http://git.xenomai.org/xenomai-3.git/commit/?id=48b2e57e29ca1c33eba14abb4b5eaa15431130fa
>>
>>
> Hi,
>
> This fix works, thanks.
>
> But will it always work in executable auto init ? The symbol
> "__real_main" have to be defined in user code if linked with bootstrap.o ?
>

__real_main() stands for the actual main as generated by the linker when
the auto-bootstrap feature is in effect (i.e. --wrap=main
--dynamic-list=...), and bootstrap.o is glued to executables/DSOs only
in such a case. IOW, __real_main() is guaranteed to exist if bootstrap.o
is part of the binary image.

So yes, we should be safe. This change has been tested with the alchemy
testsuite which is copperplate-based, a C++ application enabling
auto-init-solib, and Xenomai's base utility programs enabling the
auto-bootstrap, so far so good.

--
Philippe.



------------------------------

Message: 4
Date: Tue, 30 May 2017 17:32:09 +0430
From: ali hagigat <hagigatali@gmail.com>
To: xenomai@xenomai.org
Subject: [Xenomai] vortex86dx
Message-ID:
        <CAKKWdtfpTs1O5b-ihm2JP8vSm7KxZn7YAaOGO6Zy3H7we=SAYw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

I use xenomai for vortex86dx and cpc307 board. the kernel hangs. why?


Linux version 2.6.30 (am@localhost.localdomain) (gcc version 4.9.3
(Buildroot 2016.05) ) #6 Tue May 30 12:41:26 IRDT 2017
KERNEL supported cpus:**************************************
  Intel GenuineIntel*      Please select boot device:      *
  AMD AuthenticAMD  ****************************************
  NSC Geode by NSC  * HDD:PM-Fastwel Embedded ATA Fla      *
  Cyrix CyrixInstead* USB:JetFlash Transcend               *
  Centaur CentaurHauls<Enter Setup>                        *
  Transmeta GenuineTMx86                                   *
  Transmeta TransmetaCPU                                   *
  UMC UMC UMC UMC   *                                      *
CPU: vendor_id 'Vortex86 SoC' unknown, using generic init. *
CPU: Your system may be unstable.                          *
BIOS-provided physical RAM map:*****************************
 BIOS-e820: 0000000000000000 - 000000000009a000 (usable)   *
 BIOS-e820: 000000000009a000 - 00000000000a0000 (reserved) *
 BIOS-e820: 00000000000efff0 - 0000000000100000 (reserved) *
 BIOS-e820: 0000000000100000 - 0000000010000000 (usable)****
 BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
DMI not present or invalid.
last_pfn = 0x10000 max_arch_pfn = 0x100000
init_memory_mapping: 0000000000000000-0000000010000000
256MB LOWMEM available.
  mapped low ram: 0 - 100000004 bytes nvram
  low ram: 0 - 10000000 interface driver hiddev
  node 0 low ram: 00000000 - 10000000ver usbhid
  node 0 bootmap 00001000 - 00003000
(6 early reservations) ==> bootmem [0000000000 - 0010000000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000100000 - 000043e824]    TEXT DATA BSS ==> [0000100000 - 000043e824]
  #2 [000009a000 - 0000100000]    BIOS reserved ==> [000009a000 - 0000100000]
  #3 [000043f000 - 0000441000]              BRK ==> [000043f000 - 0000441000]4)
  #4 [0000007000 - 0000045000]          PGTABLE ==> [0000007000 - 0000045000]
  #5 [0000001000 - 0000003000]          BOOTMAP ==> [0000001000 - 0000003000]
Zone PFN ranges:correct "root=" boot option; here are the available partitions:
  DMA      0x00000000 -> 0x00001000e-gd
  Normal   0x00001000 -> 0x00010000
Movable zone start PFN for each node
early_node_map[2] active PFN rangesable to mount root fs on unknown-block(0,0)
    0: 0x00000000 -> 0x0000009aed 2.6.30 #5
    0: 0x00000100 -> 0x00010000
Allocating PCI resources starting at 20000000 (gap: 10000000:ef000000)
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64922
Kernel command line: root=/dev/sda2 nosmp tsc=reliable rootdelay=15 rw
console=ttyS0,115200n8 init=/bin/busybox init BOOT_IMAGE=bzima
Initializing CPU#0t_root+0x4f/0x57
Experimental hierarchical RCU implementation.
Experimental hierarchical RCU init done.
NR_IRQS:167>] ? kernel_init+0x0/0xb2
PID hash table entries: 1024 (order: 10, 4096 bytes)
Fast TSC calibration using PIT
Detected 599.908 MHz processor.
I-pipe 2.4-05: pipeline enabled.
Console: colour dummy device 80x25
console [ttyS0] enabled
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255720k/262144k available (2056k kernel code, 5832k reserved,
873k data, 188k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffeb000 - 0xfffff000   (  80 kB)
    vmalloc : 0xd0800000 - 0xfffe9000   ( 759 MB)
    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
      .init : 0xc03e0000 - 0xc040f000   ( 188 kB)
      .data : 0xc030224b - 0xc03dc85c   ( 873 kB)
      .text : 0xc0100000 - 0xc030224b   (2056 kB)
Checking if this processor honours the WP bit even in supervisor mode...Ok.
Calibrating delay loop (skipped), value calculated using timer
frequency.. 1199.81 BogoMIPS (lpj=5999080)
Mount-cache hash table entries: 512
CPU: Vortex86 SoC 05/02 stepping 02
Checking 'hlt' instruction... OK.
net_namespace: 296 bytes
NET: Registered protocol family 16
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
pci 0000:00:07.0: default IRQ router [17f3:6031]
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
NET: Registered protocol family 1
platform rtc_cmos: registered platform RTC device (no PNP device found)
I-pipe: Domain Xenomai registered.
Xenomai: hal/i386 started.
Xenomai: scheduling class idle registered.
Xenomai: scheduling class rt registered.
Xenomai: real-time nucleus v2.6.5 (Lost in a Memory) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
msgmni has been set to 499
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered (default)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Serial: 8250/16550 driver, 12 ports, IRQ sharing enabled
?serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
serial8250: ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
serial8250: ttyS3 at I/O 0x2e8 (irq = 3) is a 16550A
brd: module loaded
loop: module loaded
usbcore: registered new interface driver ub
Uniform Multi-Platform E-IDE driver
piix 0000:00:0c.0: IDE controller (0x17f3:0x1011 rev 0x01)
PIIX_IDE 0000:00:0c.0: guessed PCI INT A -> IRQ 14
piix 0000:00:0c.0: IDE port disabled
piix 0000:00:0c.0: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xfb00-0xfb07
hda: Fastwel Embedded ATA Flash Disk, ATA DISK drive



------------------------------

Message: 5
Date: Tue, 30 May 2017 17:04:23 +0200
From: Philippe Gerum <rpm@xenomai.org>
To: Aur?lien Le Floc'h <le.floch.aurelien94@gmail.com>,
        xenomai@xenomai.org
Subject: Re: [Xenomai] Problem with the T_LOCK
Message-ID: <f8e492cb-9b0a-ff9b-da48-5cd86a27ccb1@xenomai.org>
Content-Type: text/plain; charset=utf-8

On 05/22/2017 05:45 PM, Aur?lien Le Floc'h wrote:
> Hello everyone,
>
>
> I am working on task priority with Xenomai. I am trying to create some
> example of preemption depending on the task priority. For now I have
> some example which works thanks to new patch on Xenomai-3.0.5. To work
> on this example I work on a single core hardware (in my case a
> Raspberry Pi B+) which runs Xenomai 3 generated by Buildroot.
>
> On all this program you have one father thread which creates two
> childrens threads (child1 and child2). We are on a single core so two
> thread can?t run at the same time. In this configuration it is
> possible to provide an order of apparition of my printf. To execute
> all my program the priority order to give in entry is ./Program_name
> prio_thread_father prio_thread_child1 prio_thread_child2
>
>
> In this program (attached in this email) I am trying to use the T_LOCK
> in rt_task_create. My goal is to create the thread_father with T_LOCK
> the child1 and child2 with T_JOINABLE.
> The goal is that the father is always terminating before the child
> even if his priority is lower than the child.
>
> For example if prio_father < prio_child2 < prio_child1 this is the output
> Entry in task_father!
> End of task_father!
> Entry in task_child2!
> Entry in task_child1!
>
> Now the output is like this :
> DEBUG
> Entry in task_father!
> Entry in task_child1!
> Entry in task_child2!
> End of task_father!
>
> It's seems that the T_LOCK argument in rt_task_create has no effect
> and only the priority keeps the effect. I try to lock the scheduler
> with mutex and it's work. But my goal is to have the same result with
> T_LOCK.
> Do you have some advices ?
>

This pattern cannot work. As part of the start up protocol for a thread,
the parent explicitly blocks waiting for the child to handshake
internally, as explained earlier. A thread that blocks relinquishes the
scheduler lock while it sleeps.

My advice would be to forget about T_LOCK, this turns out to be
error-prone, especially in complex applications, not to speak of the
performance issue. If you really need some kind of thread factory,
explicit synchronization (sems, condvars) is a better option.

Besides, I would recommend to stick with POSIX if using the alchemy API
is not a requirement.

--
Philippe.



------------------------------

Message: 6
Date: Tue, 30 May 2017 18:38:30 +0200
From: Harco Kuppens <h.kuppens@cs.ru.nl>
To: xenomai@xenomai.org
Subject: [Xenomai] problem gpio interrupts xenomai3 on the raspberry
        pi 2    (or 3)
Message-ID: <46850988-a862-b747-f11d-1191f7e13458@cs.ru.nl>
Content-Type: text/plain; charset=utf-8; format=flowed

note: all resources referred to  in this email can be found in the
public repository at https://github.com/harcokuppens/xenomai3_rpi2_gpio/

At the  Radboud University Nijmegen we are already succesfully using
xenomai 2 for several years in a course about embedded systems.
Currently we are using old intel pc's which need to be replaced. The
idea is to replace them with the raspberry pi2 or pi3. We already
managed to get xenomai2 to work on the raspberry pi1 but installing
xenomai3 seems problematic and is becoming replace with the pi2 and pi3,
so we deciced to  go for the pi2 or pi3.

We found on the internet several descriptions pages which describe how
to install xenomai on a raspberry pi2/3.
An overview of these links can  be found at :
https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/overview_xenomai3_installations_found_online.txt

note: some instructions are in japanese or french but with the help of
google translate they are easy to read.

I managed to install xenomai3 on the rpi2, you can find mine
installation instructions at :

https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/install_xenomai-3-3.0.5_on_rpi2.txt

Everything seems fine except for the interrupt handling!

In
https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/button_toggles_led.png
is displayed the electronic
circuit I build to do my tests. It consists of two simple circuits :

 1.   led circuit :
    https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/led.png
 2. pullup circuit with a switch to trigger an interrupt :
    https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/circuit/pullup.png

I tried both a xenomai program in user space and kernel space
(gpiotest).  In user space the pi just hangs, and I need a hard reboot.
In kernel space no interrupt happens at all. Maybe I do something wrong
in kernel space.

At some point I was afraid that maybe my pi was broke, so I installed
the standard raspbian image, which is just linux, and runned some
interrupt test program within linux in userspace using the wiringpi
library. These programs just worked fine. My pi2 wasn't broken :)
You can find the programs at :
https://github.com/harcokuppens/xenomai3_rpi2_gpio/tree/master/examples/wiringpi_examples/

So I decided to also  test these wiringpi test programs on mine build
xenomai 3 image for the rpi2. Unfortunately the isr.c wiringpi program
didn't work anymore on mine build image. So even without using xenomai3,
but just using linux the pi2 just hangs and a hard reset was needed.

Thus I guess there is still something wrong with mine image?
Does anybody know what I'm doing wrong?
Or is this still a bug in the gpio library or in the patches applied?

Hope someone can help me, so that we can switch to xenomai3 on the
rpi2/3  in the course next semester.

Best regards,
Harco Kuppens

ps. there is a newer version of the rpi2 called v1.2  which has the same
cpu as the rpi3. But if the problem can be solved for the pi3 I'm also
very happy. I tried the same procedure for the pi3 based on the
instructions linked in
https://github.com/harcokuppens/xenomai3_rpi2_gpio/blob/master/install/overview_xenomai3_installations_found_online.txt






------------------------------

Subject: Digest Footer

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai


------------------------------

End of Xenomai Digest, Vol 61, Issue 24
***************************************



------------------------------

Subject: Digest Footer

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai


------------------------------

End of Xenomai Digest, Vol 61, Issue 25
***************************************