Building BeagleBone kernel from git

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

Quoted 8 lines · Charles Steinkuehler

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

Quoted 8 lines

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

You can use kernel from the I-pipe git at:
git://git.xenomai.org/ipipe.git branch ipipe-3.8

And xenomai from the xenomai 2.6 git at:
git://git.xenomai.org/xenomai-2.6.git branch master

The only difference in the installation procedure when using this kernel with this version of Xenomai is that the "prepare-kernel.sh" script will not apply the I-pipe patch to the kernel, since the kernel is already patched, so the argument to the "--adeos" parameter of prepare-kernel.sh is ignored.

Quoted 21 lines · Charles Steinkuehler

Quoted 8 lines

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

Quoted 8 lines

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

You can use kernel from the I-pipe git at:
git://git.xenomai.org/ipipe.git branch ipipe-3.8

Quoted 8 lines

And xenomai from the xenomai 2.6 git at:
git://git.xenomai.org/xenomai-2.6.git branch master

The only difference in the installation procedure when using this kernel with this version of Xenomai is that the "prepare-kernel.sh" script will not apply the I-pipe patch to the kernel, since the kernel is already patched, so the argument to the "--adeos" parameter of prepare-kernel.sh is ignored.

For what it's worth, I tried this procedure and documented it

https://github.com/sagarbehere/beaglebone-xenomai/blob/master/beaglebone-xenomai-debian.md

I used the for-upstream/3.8 branch, but it should be similar for the ipipe-3.8 branch.

If you improve upon the procedure, please let me know and I will update the document accordingly, or fork it and send me a pull request :)

Regards,
Sagar

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Am 20.08.2013 um 20:45 schrieb Sagar Behere <[email protected]>:

Quoted 31 lines · Gilles Chanteperdrix

Quoted 29 lines · Charles Steinkuehler

Quoted 8 lines

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

Quoted 8 lines

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

You can use kernel from the I-pipe git at:
git://git.xenomai.org/ipipe.git branch ipipe-3.8

And xenomai from the xenomai 2.6 git at:
git://git.xenomai.org/xenomai-2.6.git branch master

The only difference in the installation procedure when using this kernel with this version of Xenomai is that the "prepare-kernel.sh" script will not apply the I-pipe patch to the kernel, since the kernel is already patched, so the argument to the "--adeos" parameter of prepare-kernel.sh is ignored.

Quoted 4 lines

For what it's worth, I tried this procedure and documented it

https://github.com/sagarbehere/beaglebone-xenomai/blob/master/beaglebone-xenomai-debian.md

Gilles says: use git://git.xenomai.org/ipipe.git branch ipipe-3.8 Sagar uses git://git.xenomai.org/ipipe-jki.git origin/for-upstream/3.8

Quoted 11 lines · Charles Steinkuehler

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Quoted 5 lines

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

You can use kernel from the I-pipe git at:
git://git.xenomai.org/ipipe.git branch ipipe-3.8

And xenomai from the xenomai 2.6 git at:
git://git.xenomai.org/xenomai-2.6.git branch master

The only difference in the installation procedure when using this kernel with this version of Xenomai is that the "prepare-kernel.sh" script will not apply the I-pipe patch to the kernel, since the kernel is already patched, so the argument to the "--adeos" parameter of prepare-kernel.sh is ignored.

Quoted 16 lines · Gilles Chanteperdrix

Quoted 15 lines · Charles Steinkuehler

I am currently working with LinuxCNC in a xenomai real-time environment on the BeagleBone:

http://bb-lcnc.blogspot.com/p/machinekit_16.html

Everything is working well, but the kernel is being built using an out-of-tree patch set obtained by Michael Haberler.

I would like to switch to using a more 'official' xenomai build from git, but am unclear how to proceed.

Which git repository/branch would be the most appropriate for use in building a xenomai kernel for the BeagleBone / AM335x SoC?

Quoted 6 lines

Quoted 3 lines

Are there any 'gotchas' when using xenomai from git, or do the instructions and procedures for using a released version apply?

You can use kernel from the I-pipe git at:
git://git.xenomai.org/ipipe.git branch ipipe-3.8

Thanks! I wasn't sure if I could use one of the ipipe branches or if I still needed to use one of the personal branches.

Quoted 8 lines

And xenomai from the xenomai 2.6 git at:
git://git.xenomai.org/xenomai-2.6.git branch master

The only difference in the installation procedure when using this kernel with this version of Xenomai is that the "prepare-kernel.sh" script will not apply the I-pipe patch to the kernel, since the kernel is already patched, so the argument to the "--adeos" parameter of prepare-kernel.sh is ignored.

OK, stupid question:

I see the ipipe branch has the kernel source, but I need to apply the patches to a non-stock kernel (ie: a mainline 3.8.13 kernel patched with the BeagleBone patch set). Is there a way to get the prepare-kernel.sh script and/or a patch set to apply to a mainline kernel out of the ipipe git branch?

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines · Gilles Chanteperdrix

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

Quoted 11 lines · Charles Steinkuehler

Quoted 9 lines · Gilles Chanteperdrix

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

Problem #1 (solved): The genpatches.sh script calls awk, but seems to be incompatible with the stock awk (mawk) on my Debian Wheezy system. I was getting errors on all the match ($0, ...) lines until I installed gawk:

Quoted 4 lines · Charles Steinkuehler

Problem #1 (solved): The genpatches.sh script calls awk, but seems to be incompatible with the stock awk (mawk) on my Debian Wheezy system. I was getting errors on all the match ($0, ...) lines until I installed gawk:

I knew that, sorry for not mentioning it. And by the way, if you know how to rewrite this in portable awk, patches are welcome.

Quoted 8 lines · Gilles Chanteperdrix

Quoted 4 lines · Charles Steinkuehler

Problem #1 (solved): The genpatches.sh script calls awk, but seems to be incompatible with the stock awk (mawk) on my Debian Wheezy system. I was getting errors on all the match ($0, ...) lines until I installed gawk:

I knew that, sorry for not mentioning it. And by the way, if you know how to rewrite this in portable awk, patches are welcome.

Here you go. You have to do away with the character classes, but the gawk code is only using [:blank:] which is space and tab, so not a whole lot of horrible things to go wrong with multi-character international locales. :)

On my system this produces the exact same output using mawk as the existing code produces with gawk, but I only tested in the ipipe-3.8 branch. That said, I think I properly converted the intent of the regex matching code into something most older awk implementations can understand.

It might not be as pretty as the gawk code (I'm more used to hacking sed than awk, and the gawk extensions _are_ nifty), but it should work with most awks now.

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Quoted 15 lines · Charles Steinkuehler

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Thanks again for the help!

I managed to get a working xenomai kernel from the automated builds. I have only done light testing so far, but there didn't look to be any major issues with the process.

Additions to the "stock" RCN kernel build:

I pull the ipipe-3.8 branch from git and use it to generate an ipipe patch file

The ipipe patch is applied to a BeagleBone patched kernel tree [1]

I pull xenomai 2.6 (master) from git and run it's setup_kernel.sh on the ipipe patched source tree

...build continues as usual.

More testing needs to be done, but it looks good so far!

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

Thanks again!!

Quoted 47 lines · Charles Steinkuehler

Quoted 14 lines · Charles Steinkuehler

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Thanks again for the help!

I managed to get a working xenomai kernel from the automated builds. I have only done light testing so far, but there didn't look to be any major issues with the process.

Additions to the "stock" RCN kernel build:

I pull the ipipe-3.8 branch from git and use it to generate an ipipe patch file

The ipipe patch is applied to a BeagleBone patched kernel tree [1]

I pull xenomai 2.6 (master) from git and run it's setup_kernel.sh on the ipipe patched source tree

...build continues as usual.

More testing needs to be done, but it looks good so far!

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

Quoted 6 lines

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

As for the release date of 2.6.3 it should happen soon, but now that the I-pipe support for 3.10 is almost there, I am going to wait for it to have been tested (but not fully validated) so that 2.6.3 will be ready for 3.10.

Quoted 2 lines

Thanks again!!

Hi Gilles,
Hi Charles,

I followed this thread highly interested and built my own kernel according your advices.

By using the linux-dev repository from Robert Nelson I have built an bootable kernel image for my BeagleBone Black:

(quoted diff) +0 -3

-rwxr-xr-x 1 ralf ralf  3484720 Aug 23 16:10 3.8.13-xenomai-bone26.zImage
-rw-r--r-- 1 ralf ralf   112741 Aug 23 16:10 3.8.13-xenomai-bone26.config
-rw-r--r-- 1 ralf ralf 11865475 Aug 23 16:10

3.8.13-xenomai-bone26-modules.tar.gz
-rw-r--r-- 1 ralf ralf 1205333 Aug 23 16:10
3.8.13-xenomai-bone26-firmware.tar.gz
-rw-r--r-- 1 ralf ralf 33431 Aug 23 16:10
3.8.13-xenomai-bone26-dtbs.tar.gz

For my tests I use following file system (also from R. Nelson):
BBB-eMMC-flasher-debian-7.1-2013-07-22.img.xz
found @ http://rcn-ee.net/deb/flasher/wheezy

If I execute the following commands:
1.) boot kernel
(Info: uame -a Linux arm 3.8.13-xenomai-bone26 #2 SMP Sat Aug 24 17:14:39 CEST 2013 armv7l GNU/Linux)
2.) modprobe xeno_klat
3.) grep "TestConfig" /usr -r
(du -h /usr 255M)

I can reproduce following error (log on serial console):
Debian GNU/Linux 7 arm ttyO0

arm login:

[  200.279217] INFO: task mmcqd/1:73 blocked for more than 60 seconds.
[  200.285938] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  200.294286] mmcqd/1         D c06976c8     0    73      2 0x00000000
[  200.301177] [<c06976c8>] (__schedule+0x5b8/0x774) from [<c0695834>]
(schedule_timeout+0x1c/0x21c)
[  200.310609] [<c0695834>] (schedule_timeout+0x1c/0x21c) from
[<c0697a50>] (wait_for_common+0x130/0x170)
[  200.320537] [<c0697a50>] (wait_for_common+0x130/0x170) from
[<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74)
[  200.330791] [<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74) from
[<c051d630>] (mmc_start_req+0x50/0x158)
[  200.340758] [<c051d630>] (mmc_start_req+0x50/0x158) from [<c0528bf0>]
(mmc_blk_issue_rw_rq+0xa4/0x348)
[  200.350659] [<c0528bf0>] (mmc_blk_issue_rw_rq+0xa4/0x348) from
[<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450)
[  200.360952] [<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450) from
[<c05298cc>] (mmc_queue_thread+0xa0/0x104)
[  200.371017] [<c05298cc>] (mmc_queue_thread+0xa0/0x104) from
[<c005a69c>] (kthread+0xa0/0xb0)
[  200.380013] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.388616] Kernel panic - not syncing: hung_task: blocked tasks
[  200.395001] [<c00138dc>] (unwind_backtrace+0x0/0xe0) from
[<c06905d0>] (panic+0x84/0x1e0)
[  200.403641] [<c06905d0>] (panic+0x84/0x1e0) from [<c00943d0>]
(watchdog+0x1d4/0x234)
[  200.411843] [<c00943d0>] (watchdog+0x1d4/0x234) from [<c005a69c>]
(kthread+0xa0/0xb0)
[  200.420115] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.428645] drm_kms_helper: panic occurred, switching back to text
console
[  200.435919] Rebooting in 5 seconds..

U-Boot SPL 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

I have no idea if this blocking is caused by hard- or software. Without performing step 2, I could not reproduce this error up to now.

May be you have an idea whats going wrong here?
If you have an BBB available it would be great if you could try to reproduce this error.

Thanks and best regards
Ralf

Quoted 54 lines · Gilles Chanteperdrix

Quoted 47 lines · Charles Steinkuehler

Quoted 14 lines · Charles Steinkuehler

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Thanks again for the help!

I managed to get a working xenomai kernel from the automated builds. I have only done light testing so far, but there didn't look to be any major issues with the process.

Additions to the "stock" RCN kernel build:

I pull the ipipe-3.8 branch from git and use it to generate an ipipe patch file

The ipipe patch is applied to a BeagleBone patched kernel tree [1]

I pull xenomai 2.6 (master) from git and run it's setup_kernel.sh on the ipipe patched source tree

...build continues as usual.

More testing needs to be done, but it looks good so far!

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

Quoted 6 lines

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

Quoted 12 lines

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

As for the release date of 2.6.3 it should happen soon, but now that the I-pipe support for 3.10 is almost there, I am going to wait for it to have been tested (but not fully validated) so that 2.6.3 will be ready for 3.10.

Quoted 2 lines

Thanks again!!

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Hi Gilles,
Hi Charles,

I followed this thread highly interested and built my own kernel according your advices.

By using the linux-dev repository from Robert Nelson I have built an bootable kernel image for my BeagleBone Black:

(quoted diff) +0 -3

-rwxr-xr-x 1 ralf ralf  3484720 Aug 23 16:10 3.8.13-xenomai-bone26.zImage
-rw-r--r-- 1 ralf ralf   112741 Aug 23 16:10 3.8.13-xenomai-bone26.config
-rw-r--r-- 1 ralf ralf 11865475 Aug 23 16:10

3.8.13-xenomai-bone26-modules.tar.gz
-rw-r--r-- 1 ralf ralf 1205333 Aug 23 16:10
3.8.13-xenomai-bone26-firmware.tar.gz
-rw-r--r-- 1 ralf ralf 33431 Aug 23 16:10
3.8.13-xenomai-bone26-dtbs.tar.gz

For my tests I use following file system (also from R. Nelson):
BBB-eMMC-flasher-debian-7.1-2013-07-22.img.xz
found @ http://rcn-ee.net/deb/flasher/wheezy

If I execute the following commands:
1.) boot kernel
(Info: uame -a Linux arm 3.8.13-xenomai-bone26 #2 SMP Sat Aug 24 17:14:39 CEST 2013 armv7l GNU/Linux)
2.) modprobe xeno_klat
3.) grep "TestConfig" /usr -r
(du -h /usr 255M)

I can reproduce following error (log on serial console):
Debian GNU/Linux 7 arm ttyO0

arm login:

[  200.279217] INFO: task mmcqd/1:73 blocked for more than 60 seconds.
[  200.285938] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  200.294286] mmcqd/1         D c06976c8     0    73      2 0x00000000
[  200.301177] [<c06976c8>] (__schedule+0x5b8/0x774) from [<c0695834>]
(schedule_timeout+0x1c/0x21c)
[  200.310609] [<c0695834>] (schedule_timeout+0x1c/0x21c) from
[<c0697a50>] (wait_for_common+0x130/0x170)
[  200.320537] [<c0697a50>] (wait_for_common+0x130/0x170) from
[<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74)
[  200.330791] [<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74) from
[<c051d630>] (mmc_start_req+0x50/0x158)
[  200.340758] [<c051d630>] (mmc_start_req+0x50/0x158) from [<c0528bf0>]
(mmc_blk_issue_rw_rq+0xa4/0x348)
[  200.350659] [<c0528bf0>] (mmc_blk_issue_rw_rq+0xa4/0x348) from
[<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450)
[  200.360952] [<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450) from
[<c05298cc>] (mmc_queue_thread+0xa0/0x104)
[  200.371017] [<c05298cc>] (mmc_queue_thread+0xa0/0x104) from
[<c005a69c>] (kthread+0xa0/0xb0)
[  200.380013] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.388616] Kernel panic - not syncing: hung_task: blocked tasks
[  200.395001] [<c00138dc>] (unwind_backtrace+0x0/0xe0) from
[<c06905d0>] (panic+0x84/0x1e0)
[  200.403641] [<c06905d0>] (panic+0x84/0x1e0) from [<c00943d0>]
(watchdog+0x1d4/0x234)
[  200.411843] [<c00943d0>] (watchdog+0x1d4/0x234) from [<c005a69c>]
(kthread+0xa0/0xb0)
[  200.420115] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.428645] drm_kms_helper: panic occurred, switching back to text
console
[  200.435919] Rebooting in 5 seconds..

U-Boot SPL 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

I have no idea if this blocking is caused by hard- or software. Without performing step 2, I could not reproduce this error up to now.

May be you have an idea whats going wrong here?
If you have an BBB available it would be great if you could try to reproduce this error.

Thanks and best regards
Ralf

Quoted 66 lines · Gilles Chanteperdrix

Quoted 47 lines · Charles Steinkuehler

Quoted 14 lines · Charles Steinkuehler

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Thanks again for the help!

I managed to get a working xenomai kernel from the automated builds. I have only done light testing so far, but there didn't look to be any major issues with the process.

Additions to the "stock" RCN kernel build:

I pull the ipipe-3.8 branch from git and use it to generate an ipipe patch file

The ipipe patch is applied to a BeagleBone patched kernel tree [1]

I pull xenomai 2.6 (master) from git and run it's setup_kernel.sh on the ipipe patched source tree

...build continues as usual.

More testing needs to be done, but it looks good so far!

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

Quoted 6 lines

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

As for the release date of 2.6.3 it should happen soon, but now that the I-pipe support for 3.10 is almost there, I am going to wait for it to have been tested (but not fully validated) so that 2.6.3 will be ready for 3.10.

Quoted 2 lines

Thanks again!!

I will try to test this when I get a chance, but I'm headed out of town so it may be a while.

This error, however, is identical to hangs I get when working with a bad SD card. I had a *LOT* of those for a while, mostly on one bad SD card (that also gave hangs on x86 non-xenomai systems, so it _was_ a problem with the SD card). On the other SD cards I have, IIRC I got a few of these hangs when I first started working with the BeagleBone and haven't had any for quite some time. Other than the one actually bad SD card, it feels like the mmc driver can't handle the card re-mapping bad sectors, but that's just a guess on my part.

I'm not positive if I've seen the problem on non-xenomai kernels or just on the xenomai kernels I use for LinuxCNC. It's quite possible there's a bug either in the TI eMMC driver error handling, or perhaps the xenomai patches either add a bug or 'tickle' a bug that's already present. Have you tried your test with a non-xenomai kernel?

Quoted 148 lines

Hi Gilles,
Hi Charles,

I followed this thread highly interested and built my own kernel according your advices.

By using the linux-dev repository from Robert Nelson I have built an bootable kernel image for my BeagleBone Black:

(quoted diff) +0 -3

-rwxr-xr-x 1 ralf ralf  3484720 Aug 23 16:10 3.8.13-xenomai-bone26.zImage
-rw-r--r-- 1 ralf ralf   112741 Aug 23 16:10 3.8.13-xenomai-bone26.config
-rw-r--r-- 1 ralf ralf 11865475 Aug 23 16:10

3.8.13-xenomai-bone26-modules.tar.gz
-rw-r--r-- 1 ralf ralf 1205333 Aug 23 16:10
3.8.13-xenomai-bone26-firmware.tar.gz
-rw-r--r-- 1 ralf ralf 33431 Aug 23 16:10
3.8.13-xenomai-bone26-dtbs.tar.gz

For my tests I use following file system (also from R. Nelson):
BBB-eMMC-flasher-debian-7.1-2013-07-22.img.xz
found @ http://rcn-ee.net/deb/flasher/wheezy

If I execute the following commands:
1.) boot kernel
(Info: uame -a Linux arm 3.8.13-xenomai-bone26 #2 SMP Sat Aug 24 17:14:39 CEST 2013 armv7l GNU/Linux)
2.) modprobe xeno_klat
3.) grep "TestConfig" /usr -r
(du -h /usr 255M)

I can reproduce following error (log on serial console):
Debian GNU/Linux 7 arm ttyO0

arm login:

[  200.279217] INFO: task mmcqd/1:73 blocked for more than 60 seconds.
[  200.285938] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[  200.294286] mmcqd/1         D c06976c8     0    73      2 0x00000000
[  200.301177] [<c06976c8>] (__schedule+0x5b8/0x774) from [<c0695834>]
(schedule_timeout+0x1c/0x21c)
[  200.310609] [<c0695834>] (schedule_timeout+0x1c/0x21c) from
[<c0697a50>] (wait_for_common+0x130/0x170)
[  200.320537] [<c0697a50>] (wait_for_common+0x130/0x170) from
[<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74)
[  200.330791] [<c051c9a8>] (mmc_wait_for_req_done+0x1c/0x74) from
[<c051d630>] (mmc_start_req+0x50/0x158)
[  200.340758] [<c051d630>] (mmc_start_req+0x50/0x158) from [<c0528bf0>]
(mmc_blk_issue_rw_rq+0xa4/0x348)
[  200.350659] [<c0528bf0>] (mmc_blk_issue_rw_rq+0xa4/0x348) from
[<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450)
[  200.360952] [<c0529290>] (mmc_blk_issue_rq+0x3fc/0x450) from
[<c05298cc>] (mmc_queue_thread+0xa0/0x104)
[  200.371017] [<c05298cc>] (mmc_queue_thread+0xa0/0x104) from
[<c005a69c>] (kthread+0xa0/0xb0)
[  200.380013] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.388616] Kernel panic - not syncing: hung_task: blocked tasks
[  200.395001] [<c00138dc>] (unwind_backtrace+0x0/0xe0) from
[<c06905d0>] (panic+0x84/0x1e0)
[  200.403641] [<c06905d0>] (panic+0x84/0x1e0) from [<c00943d0>]
(watchdog+0x1d4/0x234)
[  200.411843] [<c00943d0>] (watchdog+0x1d4/0x234) from [<c005a69c>]
(kthread+0xa0/0xb0)
[  200.420115] [<c005a69c>] (kthread+0xa0/0xb0) from [<c000dc00>]
(ret_from_fork+0x18/0x38)
[  200.428645] drm_kms_helper: panic occurred, switching back to text
console
[  200.435919] Rebooting in 5 seconds..

U-Boot SPL 2013.04-00017-g5c4fa11 (May 03 2013 - 10:48:32)

I have no idea if this blocking is caused by hard- or software. Without performing step 2, I could not reproduce this error up to now.

May be you have an idea whats going wrong here?
If you have an BBB available it would be great if you could try to reproduce this error.

Thanks and best regards
Ralf

Quoted 65 lines · Gilles Chanteperdrix

Quoted 47 lines · Charles Steinkuehler

Quoted 14 lines · Charles Steinkuehler

Quoted 6 lines · Gilles Chanteperdrix

Quoted 5 lines · Charles Steinkuehler

Sorry if this is a total newbie question, but I see instructions for using the prepare-kernel.sh script on a kernel directory, and instructions for using the ipipe kernel source directly, but not how to get from one to the other.

Quoted 7 lines

You want the I-pipe patch. To generate it, in the I-pipe tree, try:

./scripts/ipipe/genpatches.sh

You should then find a file ipipe-core-3.8.13-arm-1.patch which you can try and apply to another tree, possibly additionally patching with pre and post patches (respectively before and after the I-pipe patch).

Quoted 7 lines

Yep, that sounds like exactly what I want! Thanks for the help!!

I'll report back if I run into more issues or if everything works out OK. I am trying to integrate the xenomai patches into a customized version of Robert C. Nelson's BeagleBone kernel build scripts:

https://github.com/cdsteinkuehler/linux-dev

Thanks again for the help!

I managed to get a working xenomai kernel from the automated builds. I have only done light testing so far, but there didn't look to be any major issues with the process.

Additions to the "stock" RCN kernel build:

I pull the ipipe-3.8 branch from git and use it to generate an ipipe patch file

The ipipe patch is applied to a BeagleBone patched kernel tree [1]

I pull xenomai 2.6 (master) from git and run it's setup_kernel.sh on the ipipe patched source tree

...build continues as usual.

More testing needs to be done, but it looks good so far!

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

Quoted 6 lines

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

As for the release date of 2.6.3 it should happen soon, but now that the I-pipe support for 3.10 is almost there, I am going to wait for it to have been tested (but not fully validated) so that 2.6.3 will be ready for 3.10.

Quoted 2 lines

Thanks again!!

Quoted 7 lines · Charles Steinkuehler

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

Quoted 4 lines

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

I made a pre/post patch set for the BeagleBone 3.8.13 kernel and added the files to my xenomai 2.6 repository (patch attached).

Note that I just added the files...I didn't do anything to try and integrate these with the prepare_kernel.sh script (since I'm applying the ipipe patch from git manually) or add documentation. With this, the patch generated from the current git ipipe-3.8 branch applies cleanly.

Anyway, the patch turned out to be quite simple and will hopefully roll forward fairly well.

Quoted 8 lines · Charles Steinkuehler

I made a pre/post patch set for the BeagleBone 3.8.13 kernel and added the files to my xenomai 2.6 repository (patch attached).

Note that I just added the files...I didn't do anything to try and integrate these with the prepare_kernel.sh script (since I'm applying the ipipe patch from git manually) or add documentation. With this, the patch generated from the current git ipipe-3.8 branch applies cleanly.

Quoted 2 lines

Anyway, the patch turned out to be quite simple and will hopefully roll forward fairly well.

Hi, thanks for the patch. The prepare-kernel script does not apply pre and post patches automatically, but this could be arranged. The key information to add to the documentation is the I-pipe repository/branch and commit hash to which the patch applies.

Quoted 12 lines · Gilles Chanteperdrix

Quoted 10 lines · Charles Steinkuehler

I made a pre/post patch set for the BeagleBone 3.8.13 kernel and added the files to my xenomai 2.6 repository (patch attached).

Note that I just added the files...I didn't do anything to try and integrate these with the prepare_kernel.sh script (since I'm applying the ipipe patch from git manually) or add documentation. With this, the patch generated from the current git ipipe-3.8 branch applies cleanly.

Anyway, the patch turned out to be quite simple and will hopefully roll forward fairly well.

Quoted 4 lines

Hi, thanks for the patch. The prepare-kernel script does not apply pre and post patches automatically, but this could be arranged. The key information to add to the documentation is the I-pipe repository/branch and commit hash to which the patch applies.

I mean the git repository/branch and commit hash.

Quoted 8 lines · Gilles Chanteperdrix

Quoted 7 lines · Charles Steinkuehler

[1] There was one hunk I could not get to apply automatically. The code in gpmc.c has changed extensively enough that git apply doesn't work with this file. To work around this, I skip this file when applying the ipipe patch, and use a manual fix-up of the trivial 2-line change:

https://github.com/cdsteinkuehler/linux-dev/blob/am33x-v3.8-bone26-xenomai/patches/xenomai/0001-ipipe-core-3.8.13-arm-1.gpmc.patch

Quoted 8 lines

Quoted 4 lines

There's probably a better way to work around this problem, but this should do until the next official xenomai release comes out...any day now, right?!? :) Anyway, it doesn't look like it will be that hard to roll forward with updated ipipe or xenomai patches.

The general way to handle the non-mainline kernels is with a pre and post patch. The pre patch removes the changes which conflicts, and the post patch adds the merge.

I made a pre/post patch set for the BeagleBone 3.8.13 kernel and added the files to my xenomai 2.6 repository (patch attached).

Note that I just added the files...I didn't do anything to try and integrate these with the prepare_kernel.sh script (since I'm applying the ipipe patch from git manually) or add documentation. With this, the patch generated from the current git ipipe-3.8 branch applies cleanly.

Anyway, the patch turned out to be quite simple and will hopefully roll forward fairly well.

Quoted 8 lines · Charles Steinkuehler

I made a pre/post patch set for the BeagleBone 3.8.13 kernel and added the files to my xenomai 2.6 repository (patch attached).

Note that I just added the files...I didn't do anything to try and integrate these with the prepare_kernel.sh script (since I'm applying the ipipe patch from git manually) or add documentation. With this, the patch generated from the current git ipipe-3.8 branch applies cleanly.

Quoted 2 lines

Anyway, the patch turned out to be quite simple and will hopefully roll forward fairly well.

Hi Charles,

The final version of the I-pipe patch for 3.8.13 is available, could you check the patches you posted need rebasing?