Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
On Mon, Dec 31, 2012 at 7:18 PM, Michael Haberler mai...@mah.priv.atwrote: 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 ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrus
[0.00] Total of 128 interrupts on 1 active
controller
[0.00]
omap2_gp_timer_set_mode:mode=1,clkev.rate:2400l,HZ=100
[0.00]
omap2_gp_timer_set_mode:mode=2,clkev.rate:2400l,HZ=100
[0.00] OMAP clockevent source: GPTIMER2 at 2400
Hz
[0.00] OMAP clocksource: GPTIMER3 at 2400
Hz
[0.00] I-pipe, 24.000 MHz
clocksource
[0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
1789s
[0.00] Interrupt pipeline (release
#1)
[0.00] 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:2400l,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
Re: [Xenomai] About the timer interrupt in beaglebone
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.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrus
[0.00] Total of 128 interrupts on 1 active
controller
[0.00]
omap2_gp_timer_set_mode:mode=1,clkev.rate:2400l,HZ=100
[0.00]
omap2_gp_timer_set_mode:mode=2,clkev.rate:2400l,HZ=100
[0.00] OMAP clockevent source: GPTIMER2 at 2400
Hz
[0.00] OMAP clocksource: GPTIMER3 at 2400
Hz
[0.00] I-pipe, 24.000 MHz
clocksource
[0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
1789s
[0.00] Interrupt pipeline (release
#1)
[0.00] 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:2400l,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
Re: [Xenomai] About the timer interrupt in beaglebone
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
Re: [Xenomai] About the timer interrupt in beaglebone
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. ___ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
[Xenomai] About the timer interrupt in beaglebone
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.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
interrus
[0.00] Total of 128 interrupts on 1 active
controller
[0.00]
omap2_gp_timer_set_mode:mode=1,clkev.rate:2400l,HZ=100
[0.00]
omap2_gp_timer_set_mode:mode=2,clkev.rate:2400l,HZ=100
[0.00] OMAP clockevent source: GPTIMER2 at 2400
Hz
[0.00] OMAP clocksource: GPTIMER3 at 2400
Hz
[0.00] I-pipe, 24.000 MHz
clocksource
[0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
1789s
[0.00] Interrupt pipeline (release
#1)
[0.00] 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:2400l,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
