[Xenomai] About the timer interrupt in beaglebone

[Xenomai] About the timer interrupt in beaglebone

[Bao Rui]

Hi,

I worked on the beaglebone with Xenomai, currently I meet a problem about
the timer interrupt after integrated Xenomai into my beaglebone,

The beaglebone can startup after integrating Xenomai and IPIPE, but the
timer seems not work properly. Here I add a printk in the timer interrut:
static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
{
    struct clock_event_device *evt = &clockevent_gpt;

    if (!clockevent_ipipe_stolen(evt))
        omap2_gp_timer_ack();

    if (num_online_cpus() == 1)
        __ipipe_tsc_update();
    pr_info("testtimer\n");
    evt->event_handler(evt);
    return IRQ_HANDLED;
}

And the kernel logs here:
......
NR_IRQS:396
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128
interrus
[    0.000000] Total of 128 interrupts on 1 active
controller
[    0.000000]
omap2_gp_timer_set_mode:mode=1,clkev.rate:24000000l,HZ=100
[    0.000000]
omap2_gp_timer_set_mode:mode=2,clkev.rate:24000000l,HZ=100
[    0.000000] OMAP clockevent source: GPTIMER2 at 24000000
Hz
[    0.000000] OMAP clocksource: GPTIMER3 at 24000000
Hz
[    0.000000] I-pipe, 24.000 MHz
clocksource
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
1789s
[    0.000000] Interrupt pipeline (release
#1)
[    0.000000] Console: colour dummy device
80x30
[    0.000514] Calibrating delay
loop...
[    0.009032]
testtimer
[    0.019013]
testtimer
[    0.029013]
testtimer
[    0.039013]
testtimer
[    0.049012]
testtimer
[    0.059012]
testtimer
[    0.069013]
testtimer
[    0.079012]
testtimer
[    0.089012]
testtimer
[    0.099012]
testtimer
[    0.109012]
testtimer
[    0.119012]
testtimer
[    0.119054] 718.02 BogoMIPS
(lpj=3590144)
[    0.119064] pid_max: default: 32768 minimum:
301
[    0.119196] Security Framework
initialized
[    0.119301] Mount-cache hash table entries:
512
[    0.119712] CPU: Testing write buffer coherency:
ok
[    0.129031]
testtimer
[    0.139013]
testtimer
[    0.139918] omap_hwmod: gfx: failed to
hardreset
[    0.149013]
testtimer
[    0.156191] omap_hwmod: pruss: failed to
hardreset
[    0.157420] print_constraints:
dummy:
[    0.157810] NET: Registered protocol family
16
[    0.159025]
testtimer
[    0.160259] OMAP GPIO hardware version
0.1
[    0.163100] omap_mux_init: Add partition: #1: core, flags:
0
[    0.165344]
HB:am335x_evm_i2c_init
[    0.165586]  omap_i2c.1: alias fck already
exists
[    0.166245] HB:End
am335x_evm_init
[    0.166573]  omap2_mcspi.1: alias fck already
exists
[    0.166819]  omap2_mcspi.2: alias fck already
exists
[    0.167096]  edma.0: alias fck already
exists
[    0.167117]  edma.0: alias fck already
exists
[    0.167136]  edma.0: alias fck already
exists
[    0.169030]
testtimer
[    0.179036]
testtimer
[    0.189026]
testtimer
[    0.193574] bio: create slab <bio-0> at
0
[    0.196996] usbcore: registered new interface driver
usbfs
[    0.197349] usbcore: registered new interface driver
hub
[    0.197577] usbcore: registered new device driver
usb
[    0.197725] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13,
plat_mode=0x3
[    0.198020] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13,
plat_mode=0x1
[    0.199029]
testtimer
[    0.199348] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100
kHz
[    0.200917] tps65910 1-002d: could not be
detected
[    0.202916] Switching to clocksource
ipipe_tsc
[    0.209036]
testtimer
[    0.209088]
omap2_gp_timer_set_mode:mode=3,clkev.rate:24000000l,HZ=100
[    0.219143]
testtimer
[    0.220092] musb-hdrc: version 6.0, ?dma?, otg
(peripheral+host)
[    0.220271] musb-hdrc musb-hdrc.0: dma type:
pio
[    0.221242] musb-hdrc musb-hdrc.0: USB OTG mode controller at d081c000
using8
[    0.221419] musb-hdrc musb-hdrc.1: dma type:
pio
[    0.221872] musb-hdrc musb-hdrc.1: MUSB HDRC host
driver
[    0.221949] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus
numb1
[    0.222094] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002
[    0.222110] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber1
[    0.222124] usb usb1: Product: MUSB HDRC host
driver
[    0.222135] usb usb1: Manufacturer: Linux 3.2.0
musb-hcd
[    0.222147] usb usb1: SerialNumber:
musb-hdrc.1
[    0.223028] hub 1-0:1.0: USB hub
found
[    0.223069] hub 1-0:1.0: 1 port detected

First we can see the "testtimer" logs, but after some while, this interrupt
will not enter again. If I disable the Xenomai and IPIPE, I can get the
"testtimer" working always.

If omap2_gp_timer_interrupt() does not work properly, the kernel will stop
after a msleep() call(The i2c driver will call this msleep() to read the
eeprom information).

Could you give some suggestions about this issue? I can try it on my target.

Best Regards,
Henry

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 12/23/2012 01:12 PM, Bao Rui wrote:

> Hi,
> 
> I worked on the beaglebone with Xenomai, currently I meet a problem about
> the timer interrupt after integrated Xenomai into my beaglebone,
> 
> The beaglebone can startup after integrating Xenomai and IPIPE, but the
> timer seems not work properly. Here I add a printk in the timer interrut:
> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
> {
>     struct clock_event_device *evt = &clockevent_gpt;
> 
>     if (!clockevent_ipipe_stolen(evt))
>         omap2_gp_timer_ack();
> 
>     if (num_online_cpus() == 1)
>         __ipipe_tsc_update();
>     pr_info("testtimer\n");
>     evt->event_handler(evt);
>     return IRQ_HANDLED;
> }
> 
> And the kernel logs here:
> ......
> NR_IRQS:396
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128
> interrus
> [    0.000000] Total of 128 interrupts on 1 active
> controller
> [    0.000000]
> omap2_gp_timer_set_mode:mode=1,clkev.rate:24000000l,HZ=100
> [    0.000000]
> omap2_gp_timer_set_mode:mode=2,clkev.rate:24000000l,HZ=100
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000
> Hz
> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000
> Hz
> [    0.000000] I-pipe, 24.000 MHz
> clocksource
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 1789s
> [    0.000000] Interrupt pipeline (release
> #1)
> [    0.000000] Console: colour dummy device
> 80x30
> [    0.000514] Calibrating delay
> loop...
> [    0.009032]
> testtimer
> [    0.019013]
> testtimer
> [    0.029013]
> testtimer
> [    0.039013]
> testtimer
> [    0.049012]
> testtimer
> [    0.059012]
> testtimer
> [    0.069013]
> testtimer
> [    0.079012]
> testtimer
> [    0.089012]
> testtimer
> [    0.099012]
> testtimer
> [    0.109012]
> testtimer
> [    0.119012]
> testtimer
> [    0.119054] 718.02 BogoMIPS
> (lpj=3590144)
> [    0.119064] pid_max: default: 32768 minimum:
> 301
> [    0.119196] Security Framework
> initialized
> [    0.119301] Mount-cache hash table entries:
> 512
> [    0.119712] CPU: Testing write buffer coherency:
> ok
> [    0.129031]
> testtimer
> [    0.139013]
> testtimer
> [    0.139918] omap_hwmod: gfx: failed to
> hardreset
> [    0.149013]
> testtimer
> [    0.156191] omap_hwmod: pruss: failed to
> hardreset
> [    0.157420] print_constraints:
> dummy:
> [    0.157810] NET: Registered protocol family
> 16
> [    0.159025]
> testtimer
> [    0.160259] OMAP GPIO hardware version
> 0.1
> [    0.163100] omap_mux_init: Add partition: #1: core, flags:
> 0
> [    0.165344]
> HB:am335x_evm_i2c_init
> [    0.165586]  omap_i2c.1: alias fck already
> exists
> [    0.166245] HB:End
> am335x_evm_init
> [    0.166573]  omap2_mcspi.1: alias fck already
> exists
> [    0.166819]  omap2_mcspi.2: alias fck already
> exists
> [    0.167096]  edma.0: alias fck already
> exists
> [    0.167117]  edma.0: alias fck already
> exists
> [    0.167136]  edma.0: alias fck already
> exists
> [    0.169030]
> testtimer
> [    0.179036]
> testtimer
> [    0.189026]
> testtimer
> [    0.193574] bio: create slab <bio-0> at
> 0
> [    0.196996] usbcore: registered new interface driver
> usbfs
> [    0.197349] usbcore: registered new interface driver
> hub
> [    0.197577] usbcore: registered new device driver
> usb
> [    0.197725] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13,
> plat_mode=0x3
> [    0.198020] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13,
> plat_mode=0x1
> [    0.199029]
> testtimer
> [    0.199348] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100
> kHz
> [    0.200917] tps65910 1-002d: could not be
> detected
> [    0.202916] Switching to clocksource
> ipipe_tsc
> [    0.209036]
> testtimer
> [    0.209088]
> omap2_gp_timer_set_mode:mode=3,clkev.rate:24000000l,HZ=100
> [    0.219143]
> testtimer
> [    0.220092] musb-hdrc: version 6.0, ?dma?, otg
> (peripheral+host)
> [    0.220271] musb-hdrc musb-hdrc.0: dma type:
> pio
> [    0.221242] musb-hdrc musb-hdrc.0: USB OTG mode controller at d081c000
> using8
> [    0.221419] musb-hdrc musb-hdrc.1: dma type:
> pio
> [    0.221872] musb-hdrc musb-hdrc.1: MUSB HDRC host
> driver
> [    0.221949] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus
> numb1
> [    0.222094] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [    0.222110] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber1
> [    0.222124] usb usb1: Product: MUSB HDRC host
> driver
> [    0.222135] usb usb1: Manufacturer: Linux 3.2.0
> musb-hcd
> [    0.222147] usb usb1: SerialNumber:
> musb-hdrc.1
> [    0.223028] hub 1-0:1.0: USB hub
> found
> [    0.223069] hub 1-0:1.0: 1 port detected
> 
> First we can see the "testtimer" logs, but after some while, this interrupt
> will not enter again. If I disable the Xenomai and IPIPE, I can get the
> "testtimer" working always.
> 
> If omap2_gp_timer_interrupt() does not work properly, the kernel will stop
> after a msleep() call(The i2c driver will call this msleep() to read the
> eeprom information).
> 
> Could you give some suggestions about this issue? I can try it on my target.


Hi Henry,

the beaglebone port is not part of the officile I-pipe patch, so, we
have no idea which code you are talking about, we do not even know which
version of the Linux kernel you are talking about. It seems some people
are using Xenomai on BeagleBone without any problem, so maybe they will
be able to answer your questions specifically about beagle bone.

As for debugging Xenomai on an ARM board, the only generic advices we
have are in this document:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting

Regards.


-- 
                                                                Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Michael Haberler]

Bao,

I got Xenomai working fine, based on Henri Roosen's branch: https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2

The current snapshot is here: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/xenomai-3.2.21-bb-roosen-v3.2-staging-merged but there's no essential changes wrt Henri's branch

- Michael 

Am 23.12.2012 um 13:12 schrieb Bao Rui:

> Hi,
> 
> I worked on the beaglebone with Xenomai, currently I meet a problem about
> the timer interrupt after integrated Xenomai into my beaglebone,
> 
> The beaglebone can startup after integrating Xenomai and IPIPE, but the
> timer seems not work properly. Here I add a printk in the timer interrut:
> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
> {
>   struct clock_event_device *evt = &clockevent_gpt;
> 
>   if (!clockevent_ipipe_stolen(evt))
>       omap2_gp_timer_ack();
> 
>   if (num_online_cpus() == 1)
>       __ipipe_tsc_update();
>   pr_info("testtimer\n");
>   evt->event_handler(evt);
>   return IRQ_HANDLED;
> }
> 
> And the kernel logs here:
> ......
> NR_IRQS:396
> [    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128
> interrus
> [    0.000000] Total of 128 interrupts on 1 active
> controller
> [    0.000000]
> omap2_gp_timer_set_mode:mode=1,clkev.rate:24000000l,HZ=100
> [    0.000000]
> omap2_gp_timer_set_mode:mode=2,clkev.rate:24000000l,HZ=100
> [    0.000000] OMAP clockevent source: GPTIMER2 at 24000000
> Hz
> [    0.000000] OMAP clocksource: GPTIMER3 at 24000000
> Hz
> [    0.000000] I-pipe, 24.000 MHz
> clocksource
> [    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 1789s
> [    0.000000] Interrupt pipeline (release
> #1)
> [    0.000000] Console: colour dummy device
> 80x30
> [    0.000514] Calibrating delay
> loop...
> [    0.009032]
> testtimer
> [    0.019013]
> testtimer
> [    0.029013]
> testtimer
> [    0.039013]
> testtimer
> [    0.049012]
> testtimer
> [    0.059012]
> testtimer
> [    0.069013]
> testtimer
> [    0.079012]
> testtimer
> [    0.089012]
> testtimer
> [    0.099012]
> testtimer
> [    0.109012]
> testtimer
> [    0.119012]
> testtimer
> [    0.119054] 718.02 BogoMIPS
> (lpj=3590144)
> [    0.119064] pid_max: default: 32768 minimum:
> 301
> [    0.119196] Security Framework
> initialized
> [    0.119301] Mount-cache hash table entries:
> 512
> [    0.119712] CPU: Testing write buffer coherency:
> ok
> [    0.129031]
> testtimer
> [    0.139013]
> testtimer
> [    0.139918] omap_hwmod: gfx: failed to
> hardreset
> [    0.149013]
> testtimer
> [    0.156191] omap_hwmod: pruss: failed to
> hardreset
> [    0.157420] print_constraints:
> dummy:
> [    0.157810] NET: Registered protocol family
> 16
> [    0.159025]
> testtimer
> [    0.160259] OMAP GPIO hardware version
> 0.1
> [    0.163100] omap_mux_init: Add partition: #1: core, flags:
> 0
> [    0.165344]
> HB:am335x_evm_i2c_init
> [    0.165586]  omap_i2c.1: alias fck already
> exists
> [    0.166245] HB:End
> am335x_evm_init
> [    0.166573]  omap2_mcspi.1: alias fck already
> exists
> [    0.166819]  omap2_mcspi.2: alias fck already
> exists
> [    0.167096]  edma.0: alias fck already
> exists
> [    0.167117]  edma.0: alias fck already
> exists
> [    0.167136]  edma.0: alias fck already
> exists
> [    0.169030]
> testtimer
> [    0.179036]
> testtimer
> [    0.189026]
> testtimer
> [    0.193574] bio: create slab <bio-0> at
> 0
> [    0.196996] usbcore: registered new interface driver
> usbfs
> [    0.197349] usbcore: registered new interface driver
> hub
> [    0.197577] usbcore: registered new device driver
> usb
> [    0.197725] musb-ti81xx musb-ti81xx: musb0, board_mode=0x13,
> plat_mode=0x3
> [    0.198020] musb-ti81xx musb-ti81xx: musb1, board_mode=0x13,
> plat_mode=0x1
> [    0.199029]
> testtimer
> [    0.199348] omap_i2c omap_i2c.1: bus 1 rev2.4.0 at 100
> kHz
> [    0.200917] tps65910 1-002d: could not be
> detected
> [    0.202916] Switching to clocksource
> ipipe_tsc
> [    0.209036]
> testtimer
> [    0.209088]
> omap2_gp_timer_set_mode:mode=3,clkev.rate:24000000l,HZ=100
> [    0.219143]
> testtimer
> [    0.220092] musb-hdrc: version 6.0, ?dma?, otg
> (peripheral+host)
> [    0.220271] musb-hdrc musb-hdrc.0: dma type:
> pio
> [    0.221242] musb-hdrc musb-hdrc.0: USB OTG mode controller at d081c000
> using8
> [    0.221419] musb-hdrc musb-hdrc.1: dma type:
> pio
> [    0.221872] musb-hdrc musb-hdrc.1: MUSB HDRC host
> driver
> [    0.221949] musb-hdrc musb-hdrc.1: new USB bus registered, assigned bus
> numb1
> [    0.222094] usb usb1: New USB device found, idVendor=1d6b,
> idProduct=0002
> [    0.222110] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber1
> [    0.222124] usb usb1: Product: MUSB HDRC host
> driver
> [    0.222135] usb usb1: Manufacturer: Linux 3.2.0
> musb-hcd
> [    0.222147] usb usb1: SerialNumber:
> musb-hdrc.1
> [    0.223028] hub 1-0:1.0: USB hub
> found
> [    0.223069] hub 1-0:1.0: 1 port detected
> 
> First we can see the "testtimer" logs, but after some while, this interrupt
> will not enter again. If I disable the Xenomai and IPIPE, I can get the
> "testtimer" working always.
> 
> If omap2_gp_timer_interrupt() does not work properly, the kernel will stop
> after a msleep() call(The i2c driver will call this msleep() to read the
> eeprom information).
> 
> Could you give some suggestions about this issue? I can try it on my target.
> 
> Best Regards,
> Henry
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 12/31/2012 05:39 PM, Michael Haberler wrote:

> Bao,
> 
> I got Xenomai working fine, based on Henri Roosen's branch: https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2


Hi Michael,

if you tell us on which unpatched kernel this branch is based, we could
generate the pre- and post- patches we have been talking about.

Regards.


-- 
                                                                Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Michael Haberler]

Hi Gilles,


I would think Henri is in better position to explain the genealogy; the way I understand it is is a merge of torvalds 3.2.21 onto this TI 3.2 branch: http://arago-project.org/git/projects/linux-am33x.git?p=projects/linux-am33x.git;a=commit;h=d7e124e8074cccf9958290e773c88a4b2b36412b

Henri told me this:

> I made this tree for supporting the AM335x-evm board. The beaglebone is untested with this tree.
> This posting and thread sums what I did to get the tree http://www.xenomai.org/pipermail/xenomai/2012-October/026594.html.

I took Henri's branch and merged http://arago-project.org/git/projects/linux-am33x.git?p=projects/linux-am33x.git;a=shortlog;h=refs/heads/v3.2-staging where all the 3.2 related fixes show up.

I wound up with this configuration; http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/blob/ce9f5236ec183aff622ffc4c59e331957167f934:/arch/arm/configs/mah_bbone_defconfig  which works fine for a few people working on LinuxCNC on the beaglebone in a tftp boot/nfs root setting.

I'm sorry to be fuzzy/slightly belletristic on this, I'm not very firm in this space. I am also a tad confused by the number of options - there's the Arago project sources which look 'most TI official' to me, then the Koen Koi kernels, and the Robert C Nelson kernels (both on github) with a bewildering variety of branches.

I did try to replicate Stephan Kappertz's work, as well Sheng Chao's, both of which went nowhere for me, but that doesnt mean they dont work; just not for me.


- Michael



Am 31.12.2012 um 18:31 schrieb Gilles Chanteperdrix:

> On 12/31/2012 05:39 PM, Michael Haberler wrote:
> 
>> Bao,
>> 
>> I got Xenomai working fine, based on Henri Roosen's branch: https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2
> 
> 
> Hi Michael,
> 
> if you tell us on which unpatched kernel this branch is based, we could
> generate the pre- and post- patches we have been talking about.
> 
> Regards.
> 
> 
> -- 
>                                                                Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Henri Roosen]

On Mon, Dec 31, 2012 at 7:18 PM, Michael Haberler <mail17@mah.priv.at>wrote:

> Hi Gilles,
>
>
> I would think Henri is in better position to explain the genealogy; the
> way I understand it is is a merge of torvalds 3.2.21 onto this TI 3.2
> branch:
> http://arago-project.org/git/projects/linux-am33x.git?p=projects/linux-am33x.git;a=commit;h=d7e124e8074cccf9958290e773c88a4b2b36412b
>
> Henri told me this:
>
> > I made this tree for supporting the AM335x-evm board. The beaglebone is
> untested with this tree.
> > This posting and thread sums what I did to get the tree
> http://www.xenomai.org/pipermail/xenomai/2012-October/026594.html.
>

That post sums up well what I did to get to what I pushed to github. The
core-3.2 patch was from commit 8d70b0110a15beed9e4d692a49775bff9f575280.

Note that this was just a quick port to the AM335x-evm board which I only
used for evaluating our application on this board. There are some shortcuts
that need proper solving (and some hooks specific to our application that
got pushed by accident). Actually it was pushed to github only to guide
Stefan Videv to bring up Xenomai on his AM335x-evm board.

I took Henri's branch and merged
> http://arago-project.org/git/projects/linux-am33x.git?p=projects/linux-am33x.git;a=shortlog;h=refs/heads/v3.2-stagingwhere all the 3.2 related fixes show up.
>
> I wound up with this configuration;
> http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/blob/ce9f5236ec183aff622ffc4c59e331957167f934:/arch/arm/configs/mah_bbone_defconfig which works fine for a few people working on LinuxCNC on the beaglebone in
> a tftp boot/nfs root setting.
>
> I'm sorry to be fuzzy/slightly belletristic on this, I'm not very firm in
> this space. I am also a tad confused by the number of options - there's the
> Arago project sources which look 'most TI official' to me, then the Koen
> Koi kernels, and the Robert C Nelson kernels (both on github) with a
> bewildering variety of branches.
>

My decision to base the port on the Arago project was also that it looked
'most TI official' to me. TI ships an evaluation disk with the AM335x-evm
board that is based on this project.


> I did try to replicate Stephan Kappertz's work, as well Sheng Chao's, both
> of which went nowhere for me, but that doesnt mean they dont work; just not
> for me.
>
>
> - Michael
>
>
>
> Am 31.12.2012 um 18:31 schrieb Gilles Chanteperdrix:
>
> > On 12/31/2012 05:39 PM, Michael Haberler wrote:
> >
> >> Bao,
> >>
> >> I got Xenomai working fine, based on Henri Roosen's branch:
> https://github.com/roosen/linux/tree/v3.2.21_AM33xx_core-3.2
> >
> >
> > Hi Michael,
> >
> > if you tell us on which unpatched kernel this branch is based, we could
> > generate the pre- and post- patches we have been talking about.
>

I still have the evaluation board on my desk. If there will be pre- and
post- patches please let me know and I will be happy to test these on the
AM335x-evm board. My focus for the coming weeks will be on the iMX6 based
(SabreLite) boards, but if cooking up the pre- and post- patches takes
little time and someone wants to guide me I am happy to help out there too.


> >
> > Regards.
> >
> >
> > --
> >                                                                Gilles.
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote:
> 
> My decision to base the port on the Arago project was also that it looked
> 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm
> board that is based on this project.

The arago thing has gazillions of hacks, must of which are never going
mainline. I would avoid it if at all possible.

I have been pushing to get the beaglebone working "out of the box" in
mainline Linux, and as of v3.8-rc2 it does work with a ramfs and
Ethernet networking. However, I don't know which other drivers are
still not working on that board.

HTH,
Richard

Re: [Xenomai] About the timer interrupt in beaglebone

[Michael Haberler]

Am 03.01.2013 um 09:53 schrieb Richard Cochran:

> On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote:
>> 
>> My decision to base the port on the Arago project was also that it looked
>> 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm
>> board that is based on this project.
> 
> The arago thing has gazillions of hacks, must of which are never going
> mainline. I would avoid it if at all possible.
> 
> I have been pushing to get the beaglebone working "out of the box" in
> mainline Linux, and as of v3.8-rc2 it does work with a ramfs and
> Ethernet networking. However, I don't know which other drivers are
> still not working on that board.

Richard -

fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon

what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list?

- Michael

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Thu, Jan 03, 2013 at 10:18:15AM +0100, Michael Haberler wrote:
> 
> fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon
> 
> what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list?

I guess that the best way forward would be:

1. Try vanilla v3.8 and see if the drivers you need are working.
2. If so, then help to update the arm ipipe patch to v3.8.

But of course, it depends on how much time and effort you are willing
to spend. Just be aware that if you develop on top of some random,
hacked up vendor kernel, then it probably will end up as a dead end,
and you efforts might be wasted.

I wouldn't necessarily say that updating ipipe is harder than chasing
and fixing TI's hacks.

HTH,
Richard

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 01/03/2013 03:15 PM, Richard Cochran wrote:

> On Thu, Jan 03, 2013 at 10:18:15AM +0100, Michael Haberler wrote:
>>
>> fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon
>>
>> what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list?
> 
> I guess that the best way forward would be:
> 
> 1. Try vanilla v3.8 and see if the drivers you need are working.
> 2. If so, then help to update the arm ipipe patch to v3.8.
> 
> But of course, it depends on how much time and effort you are willing
> to spend. Just be aware that if you develop on top of some random,
> hacked up vendor kernel, then it probably will end up as a dead end,
> and you efforts might be wasted.
> 
> I wouldn't necessarily say that updating ipipe is harder than chasing
> and fixing TI's hacks.


The advantage of TI's trees is that:
- they are available way before any code equivalent to the one they
contain is available in mainline, some drivers may never make it to
mainline anyway;
- their SDKs are based on it.

Of course some of the code they contain is not really acceptable in
mainline, but at least it is there and takes less time to debug than it
would if starting from scratch.

The fact that they remain with one kernel release is only an issue on
the long term, but since on the long term, you have chances to use the
next TI product, which will mean a newer kernel, maybe you will never
care about trying and updating the kernel for the old TI product.

Just trying to give a different opinion from Richard.

-- 
                                                                Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Thu, Jan 03, 2013 at 09:19:37PM +0100, Gilles Chanteperdrix wrote:

> Of course some of the code they contain is not really acceptable in
> mainline, but at least it is there and takes less time to debug than it
> would if starting from scratch.

That it takes "less time" is only sometimes true.
 
> Just trying to give a different opinion from Richard.

I actually agree with you, Gilles. If you are developing a consumer device

  - with a three year product lifetime
  - that will never receive a firmware upgrade
  - where time to market is most important

then the TI kernel is the best choice. But if you want to build, let's
say, a platform for a family of products with a five to ten year
scope, then maybe using TI's heavily modified v3.2 kernel is not best
way.

In any case, what is clearly best for the community is having mainline
support. I myself am interested in and am willing to help out with
xenomai on the beaglebone, but I will not waste my time with the TI
kernel. It is just too far away for me.

Thanks,
Richard

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 01/04/2013 09:50 AM, Richard Cochran wrote:
> On Thu, Jan 03, 2013 at 09:19:37PM +0100, Gilles Chanteperdrix wrote:
> 
>> Of course some of the code they contain is not really acceptable in
>> mainline, but at least it is there and takes less time to debug than it
>> would if starting from scratch.
> 
> That it takes "less time" is only sometimes true.

Well, at some point you can still decide to abandon the vendor driver
and start from scratch.

>  
>> Just trying to give a different opinion from Richard.
> 
> I actually agree with you, Gilles. If you are developing a consumer device
> 
>   - with a three year product lifetime
>   - that will never receive a firmware upgrade

Thanks to the stable kernel releases, a kernel still gets updates for
security fixes. A product I have worked on around three years ago used
the 2.6.32 kernel from the "arago" tree, this looks old, but on the
other hand, the debian stable distribution default kernel running on the
xenomai.org server is also based on the 2.6.32 kernel.

>   - where time to market is most important
> 
> then the TI kernel is the best choice. But if you want to build, let's
> say, a platform for a family of products with a five to ten year
> scope, then maybe using TI's heavily modified v3.2 kernel is not best
> way.
> 
> In any case, what is clearly best for the community is having mainline
> support. I myself am interested in and am willing to help out with
> xenomai on the beaglebone, but I will not waste my time with the TI
> kernel. It is just too far away for me.

I agree with that too, and I would like to help mainline the support for
the TI processors I am using at work, but the fact is that at work, I do
not really have time to do it, because the drivers for the TI processor
I am working with (the TI processors for video encoding, ex-DaVinci
family) represent big masses of code, and getting code into mainline
means many iterations, especially for someone who does not do it often,
and at home, well, most of the time I devote to free-software
contributions is devoted to the xenomai project. Maybe I was discouraged
by the attempt of contributing the FCSE patch too.

The effort should come from TI, because if the support for new
processors directly lands into mainline, we will no longer have to
choose between the vendor kernel and the mainline kernel. I guess that
is the point of having created Linaro.

-- 
					    Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Fri, Jan 04, 2013 at 10:50:07AM +0100, Gilles Chanteperdrix wrote:
> 
> Well, at some point you can still decide to abandon the vendor driver
> and start from scratch.

Well, yes, you will probably only do this when you have to.

And then you will cry a tear for your wasted efforts :,(

> Thanks to the stable kernel releases, a kernel still gets updates for
> security fixes. 

But not for TI's out of tree bugs.

> A product I have worked on around three years ago used
> the 2.6.32 kernel from the "arago" tree, this looks old, but on the
> other hand, the debian stable distribution default kernel running on the
> xenomai.org server is also based on the 2.6.32 kernel.

But does debian have as many custom patches as TI? I would guess not.

> I agree with that too, and I would like to help mainline the support for
> the TI processors I am using at work, but the fact is that at work, I do
> not really have time to do it, because the drivers for the TI processor
> I am working with (the TI processors for video encoding, ex-DaVinci
> family) represent big masses of code, and getting code into mainline
> means many iterations, especially for someone who does not do it often,
> and at home, well, most of the time I devote to free-software
> contributions is devoted to the xenomai project. Maybe I was discouraged
> by the attempt of contributing the FCSE patch too.

FCSE is a special, esoteric case I think. New drivers are not so hard
to get merged, but you are right about the iterations.

> The effort should come from TI, because if the support for new
> processors directly lands into mainline, we will no longer have to
> choose between the vendor kernel and the mainline kernel. I guess that
> is the point of having created Linaro.

Yep, but TI is only willing to spend so much effort. It is frustrating
to watch how they and other vendors go about their Linux support.

Thanks,
Richard

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 01/04/2013 11:04 AM, Richard Cochran wrote:
> FCSE is a special, esoteric case I think. New drivers are not so hard
> to get merged, but you are right about the iterations.

Is it? Still working on that consumer device I have another example of
patch that never made it to mainline. Maybe simply different communities
have different goals?

http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021885.html

https://lkml.org/lkml/2011/2/3/43

for a consumer device, it makes sense to continue working properly even
if a storage device was removed uncleanly, the linux community, on the
other hand, may consider this issue a corner case, just like using the FCSE.

-- 
					    Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote:
> On 01/04/2013 11:04 AM, Richard Cochran wrote:
> > FCSE is a special, esoteric case I think. New drivers are not so hard
> > to get merged, but you are right about the iterations.
> 
> Is it? Still working on that consumer device I have another example of
> patch that never made it to mainline. Maybe simply different communities
> have different goals?
> 
> http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-January/021885.html
> 
> https://lkml.org/lkml/2011/2/3/43

Looks like this patch didn't go to the arm list, the arm maintainer,
or the soc mainainter, and it probably should have. In any case, if a
patch gets ignored, then it is okay to nag* the gate keepers until
they respond. The squeaky wheel gets the grease, you know.

I was able to push the beaglebone to the present (v3.8-rc2) state of
actually booting with Ethernet working only by kicking and screaming
on the arm list. The real problem there is the TI people who are
posting the the lists, but fail to follow through, saying things like

  "it is already working" (but only with their out of tree patches)

and

  "we submitted a patch that will appear soon" (but the patch is only
  on some omap list an not in maintainer tree)

and

  "yes, we got driver merged into the tree, but it is not our fault
  that it doesn't actually work."

The TI people are clearly focused on their arago-whatever trees, and
they are not gettings things done for mainline.

That is the whole problem.

Thanks,
Richard

* Post to the arm list. That is the one that counts.

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 01/04/2013 05:02 PM, Richard Cochran wrote:
> I was able to push the beaglebone to the present (v3.8-rc2) state of
> actually booting with Ethernet working only by kicking and screaming
> on the arm list.

IIRC, you also had to kick and scream for ixp4xx fixes, and getting
clock synchronization through IEEE 1588, and no TI maintainer was
involved. So, I may be stating the obvious, but it seems to me that we
you are new to the exercise, getting code merged into mainline is not
that easy, perhaps both because you may not do it the way the known
maintainers/contributors expect you to do it, and because the
maintainers/contributors do not tend to trust someone they do not know.
Most people involved in short term projects simply give up after the
first rejection.

> The real problem there is the TI people who are
> posting the the lists, but fail to follow through, saying things like
> 
>   "it is already working" (but only with their out of tree patches)
> 
> and
> 
>   "we submitted a patch that will appear soon" (but the patch is only
>   on some omap list an not in maintainer tree)

These excuses look a lot like the ones which happen with xenomai between
the time a fix happens in the git tree and a release or between the time
a fix happen in my ipipe git, and is merged in the official ipipe git,
if you get a link to the actual patch, I do not see how else things
could be handled. If the patch is finally merged, this is not really a
problem.

> 
> and
> 
>   "yes, we got driver merged into the tree, but it is not our fault
>   that it doesn't actually work."

we try to avoid that here...

> 
> The TI people are clearly focused on their arago-whatever trees, and
> they are not gettings things done for mainline.

I am afraid the code contained in the arago tree is not entirely
developed by TI people, the people having to maintain it may not be the
ones who wrote it. That may make getting things done for mainline a tad
harder.

> * Post to the arm list. That is the one that counts.

I knew that, I even said it:
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-February/021979.html

The FCSE patch was certainly posted to the lakml, but someone told me
"you should have sent a mail to rmk as well". What? rmk is not reading
the lakml? Sometimes, the rules for posting to a list (like never
posting a patch for review during the merge window) are a bit hard for
the newcomer, especially when they are of the kind "it is not written
anywhere, it is obvious, everybody knows that".

-- 
					    Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Richard Cochran]

On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote:
> 
> https://lkml.org/lkml/2011/2/3/43

Also, that patch says "RFC". After getting no feedback, I would have
resubmitted a "bugfix" or something more assertive in the subject
line.

Thanks,
Richard

Re: [Xenomai] About the timer interrupt in beaglebone

[Gilles Chanteperdrix]

On 01/04/2013 05:08 PM, Richard Cochran wrote:
> On Fri, Jan 04, 2013 at 03:16:12PM +0100, Gilles Chanteperdrix wrote:
>>
>> https://lkml.org/lkml/2011/2/3/43
> 
> Also, that patch says "RFC". After getting no feedback, I would have
> resubmitted a "bugfix" or something more assertive in the subject
> line.

The thing is, if you look at the contents of the patch, it is almost
certainly not the right thing to do.

-- 
					    Gilles.

Re: [Xenomai] About the timer interrupt in beaglebone

[Jack Mitchell]

On 03/01/2013 09:18, Michael Haberler wrote:
> Am 03.01.2013 um 09:53 schrieb Richard Cochran:
>
>> On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote:
>>> My decision to base the port on the Arago project was also that it looked
>>> 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm
>>> board that is based on this project.
>> The arago thing has gazillions of hacks, must of which are never going
>> mainline. I would avoid it if at all possible.
>>
>> I have been pushing to get the beaglebone working "out of the box" in
>> mainline Linux, and as of v3.8-rc2 it does work with a ramfs and
>> Ethernet networking. However, I don't know which other drivers are
>> still not working on that board.
> Richard -
>
> fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon
>
> what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list?

OT: I would suggest now starting with [1] for any beaglebone based work. 
The only thing that I'm not sure about is PRU support.

Regards,
Jack

[1] https://github.com/beagleboard/kernel/tree/3.8

>
> - Michael
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] About the timer interrupt in beaglebone

[Michael Haberler]

Jack,

Am 03.01.2013 um 23:00 schrieb Jack Mitchell:

> On 03/01/2013 09:18, Michael Haberler wrote:
>> Am 03.01.2013 um 09:53 schrieb Richard Cochran:
>> 
>>> On Wed, Jan 02, 2013 at 10:40:05AM +0100, Henri Roosen wrote:
>>>> My decision to base the port on the Arago project was also that it looked
>>>> 'most TI official' to me. TI ships an evaluation disk with the AM335x-evm
>>>> board that is based on this project.
>>> The arago thing has gazillions of hacks, must of which are never going
>>> mainline. I would avoid it if at all possible.
>>> 
>>> I have been pushing to get the beaglebone working "out of the box" in
>>> mainline Linux, and as of v3.8-rc2 it does work with a ramfs and
>>> Ethernet networking. However, I don't know which other drivers are
>>> still not working on that board.
>> Richard -
>> 
>> fine, but my requirement is a working Xenomai kernel with - in the minimum - GPIO, PRU, PWM, cape support, and I dont see that combination of Xenomai and v.3.8 around the corner anyday soon
>> 
>> what would you then suggest as an alternative base for getting Xenomai to run on the beaglebone with the above laundry list?
> 
> OT: I would suggest now starting with [1] for any beaglebone based work. The only thing that I'm not sure about is PRU support.

it looks like PRU support is in fact included:

config: https://github.com/beagleboard/kernel/commit/fb146ec635a8a6cab3527a924a0e068d382f2549

driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/uio/uio_pruss.c;h=6e2ab007fe9c03fc7768bf84144155f73e1bd871;hb=d1c3ed669a2d452cacfb48c2d171a1f364dae2ed

thanks!

Michael

ps: OT - we have a 200kHz software stepper motor driver running on the PRU by now - while the main CPU is idle; there's no realistic chance of getting anywhere near this figure without the PRU

> 
> Regards,
> Jack
> 
> [1] https://github.com/beagleboard/kernel/tree/3.8
> 
>> 
>> - Michael
>> 
>> 
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
> 
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai