BeagleBone Black switching to 3.14 kernel

[Jason Kridner]

It is time to make another big software push for BeagleBone Black. We
have several recent updates from Robert, including managing the kernel
as Debian packages.

To try out the new code, use one of the recent images from:
http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05

Then, you'll need to switch to the 3.14 kernel:
sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r10

Report issues to one of these trackers:
https://github.com/beagleboard/linux
http://bugs.elinux.org/projects/debian-image-releases

The device tree overlay support is still under development as is
built-in 'config-pin/cape-universal' support, so static configuration
of the .dtb is currently required. Your help is requested to make sure
the default .dtb file includes as many configurations as possible that
can be enabled from userspace.

Update summary:
* Repo moved to https://github.com/beagleboard/linux
* Layout of Debian images now enable 'apt-get' updates to the kernel,
but you need to grab a newer starting distro image
* The false-start on the cape-firmware repo has been abandoned and
device tree overlays are now part of the kernel tree
* The kernel currently uses DMA for the USB and includes SGX support

I've setup a buildbot hosted at http://builds.beagleboard.org, but I'm
still working on getting it to handle pull requests, multiple
branches, etc. like the MachineKit folks are doing, as well as pushing
out the builds.

After a bit more feedback, I'll push out some blog posts, etc. to get
more people involved. Thanks for your help!

[William Hermans]

The device tree overlay support is still under development as is
built-in 'config-pin/cape-universal' support, so static configuration
of the .dtb is currently required. Your help is requested to make sure
the default .dtb file includes as many configurations as possible that
can be enabled from userspace.

Would it not be prudent to at least provide *some* mechanism to disable / enable device tree files. Before moving to the "next latest greatest" ? Sure, hacking the main firmware file works I suppose, but that is not a real solution.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Mon, Aug 18, 2014 at 5:40 AM, William Hermans <yyr...@gmail.com> wrote:
>> The device tree overlay support is still under development as is
>> built-in 'config-pin/cape-universal' support, so static configuration
>> of the .dtb is currently required. Your help is requested to make sure
>> the default .dtb file includes as many configurations as possible that
>> can be enabled from userspace.
>
>
> Would it not be prudent to at least provide *some* mechanism to disable /
> enable device tree files. Before moving to the "next latest greatest" ?
> Sure, hacking the main firmware file works I suppose, but that is not a real
> solution.

We are going to try and do as much as possible in userspace, using
idea's from Charles's universal pinmux.

For stuff that we can't use that for, we are doing:

https://github.com/beagleboard/linux/blob/3.14/arch/arm/boot/dts/am335x-boneblack.dts#L30

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Jason Kridner]

On Mon, Aug 18, 2014 at 6:40 AM, William Hermans <yyr...@gmail.com> wrote:

The device tree overlay support is still under development as is
built-in 'config-pin/cape-universal' support, so static configuration
of the .dtb is currently required. Your help is requested to make sure
the default .dtb file includes as many configurations as possible that
can be enabled from userspace.

Would it not be prudent to at least provide *some* mechanism to disable / enable device tree files. Before moving to the "next latest greatest" ? Sure, hacking the main firmware file works I suppose, but that is not a real solution.

Absolutely. I don't think we'll switch this to the default kernel until we enable device tree overlay support and CapeMgr, but I'm asking for help in the meantime in enabling as much as possible using config-pin/cape-universal and the gpio/pinmux helpers. For power and many more reasons, it will be better to have a more trimmed down .dtb, but I believe ease-of-use will be greatly improved by making overlays the exception rather than the rule.

[Brent]

Thanks for the update Jason... I didn't realize the kernel repo had moved - I was wondering why there wasn't much activity recently!  I was looking at the 3.8 branch and noticed that Robert had added SGX... it would appear that 3.8 will also now have SGX working, not only 3.14, right?  I didn't see any commits regarding DMA for USB though...

[Cedric Malitte]

Thanks for posting,
I'll try that ;)

[William Hermans]

So, at this point in time. What can we expect that is better with 3.14 versus 3.8 ? I do not personally have a problem using #include for various "capes" if need be, but I am wondering if USB hotplug, and / or if USB support is better. As was with 3.15.

On Wed, Sep 10, 2014 at 5:42 PM, Cedric Malitte <cedric....@gmail.com> wrote:

Thanks for posting,
I'll try that ;)

[Robert Nelson]

On Wed, Sep 10, 2014 at 8:02 PM, William Hermans <yyr...@gmail.com> wrote:
> So, at this point in time. What can we expect that is better with 3.14
> versus 3.8 ? I do not personally have a problem using #include for various
> "capes" if need be, but I am wondering if USB hotplug, and / or if USB
> support is better. As was with 3.15.

usb/ethernet/pm is better.

Right now we are integrating Charles's universal pinmux, which will
allow you to 'mux' enabled peripherals on the fly.

[William Hermans]

Thanks Robert. pm == power management ? If so how is it better ?

[Robert Nelson]

On Wed, Sep 10, 2014 at 8:41 PM, William Hermans <yyr...@gmail.com> wrote:
> Thanks Robert. pm == power management ? If so how is it better ?

echo mem > /sys/power/state

actually works..

[William Hermans]

Very nice. thanks Robert.

[neo]

Will the kernel have PREEMPT enabled as its now disabled for debian ?

[Ben Gamari]

Jason Kridner <jkri...@beagleboard.org> writes:

> It is time to make another big software push for BeagleBone Black. We
> have several recent updates from Robert, including managing the kernel
> as Debian packages.
>
> To try out the new code, use one of the recent images from:
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
>
> Then, you'll need to switch to the 3.14 kernel:
> sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r10
>

It seems like this image has a greatly reduced set of modules (namely
the `rt2x00` driver isn't built, although looking at the .config diff it
looks like many drivers are omitted). Could the build configuration be
modified to include a wider breadth of drivers?

Out of curiosity, currently apt knows of three kernel series (run on a
2014-09-03 installation): `-ti`, `-bone`, and what is presumably the
unsuffixed Debian upstream kernels. From what trees do these builds
originate? Who maintains them? I guess the `-ti` kernel is new
preferred kernel?

Cheers,

- Ben

[Robert Nelson]

On Fri, Sep 12, 2014 at 12:21 PM, Ben Gamari <bgamar...@gmail.com> wrote:
> Jason Kridner <jkri...@beagleboard.org> writes:
>
>> It is time to make another big software push for BeagleBone Black. We
>> have several recent updates from Robert, including managing the kernel
>> as Debian packages.
>>
>> To try out the new code, use one of the recent images from:
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
>>
>> Then, you'll need to switch to the 3.14 kernel:
>> sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r10
>>
> It seems like this image has a greatly reduced set of modules (namely
> the `rt2x00` driver isn't built, although looking at the .config diff it
> looks like many drivers are omitted). Could the build configuration be
> modified to include a wider breadth of drivers?

enabled them last week:

sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r19

( i need to add a : linux-image-bb.org-v3.14-meta-package )

> Out of curiosity, currently apt knows of three kernel series (run on a
> 2014-09-03 installation): `-ti`, `-bone`, and what is presumably the
> unsuffixed Debian upstream kernels. From what trees do these builds
> originate? Who maintains them? I guess the `-ti` kernel is new
> preferred kernel?

So the "-bone" is close to mainline (small # of patches). The "-ti" we
are a basing on a ti branch: (git.ti.com, patchset >20Mb).. Plus the
'debian' linux-image-armmp will also work once we switch to jessie..
(you can even install ubuntu's linux-image *.deb) the bootloader will
find it.

v3.14-ti repo: https://github.com/beagleboard/linux/tree/3.14

[Ben Gamari]

Robert Nelson <robert...@gmail.com> writes:

> On Fri, Sep 12, 2014 at 12:21 PM, Ben Gamari <bgamar...@gmail.com> wrote:
>> Jason Kridner <jkri...@beagleboard.org> writes:
>>
>>> It is time to make another big software push for BeagleBone Black. We
>>> have several recent updates from Robert, including managing the kernel
>>> as Debian packages.
>>>
>>> To try out the new code, use one of the recent images from:
>>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
>>>
>>> Then, you'll need to switch to the 3.14 kernel:
>>> sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r10
>>>
>> It seems like this image has a greatly reduced set of modules (namely
>> the `rt2x00` driver isn't built, although looking at the .config diff it
>> looks like many drivers are omitted). Could the build configuration be
>> modified to include a wider breadth of drivers?
>
> enabled them last week:
>
> sudo apt-get update ; sudo apt-get install linux-image-3.14.17-ti-r19
>

Oops, should have checked this.

> ( i need to add a : linux-image-bb.org-v3.14-meta-package )
>
>> Out of curiosity, currently apt knows of three kernel series (run on a
>> 2014-09-03 installation): `-ti`, `-bone`, and what is presumably the
>> unsuffixed Debian upstream kernels. From what trees do these builds
>> originate? Who maintains them? I guess the `-ti` kernel is new
>> preferred kernel?
>
> So the "-bone" is close to mainline (small # of patches). The "-ti" we
> are a basing on a ti branch: (git.ti.com, patchset >20Mb).. Plus the
> 'debian' linux-image-armmp will also work once we switch to jessie..
> (you can even install ubuntu's linux-image *.deb) the bootloader will
> find it.
>
> v3.14-ti repo: https://github.com/beagleboard/linux/tree/3.14
>

Thanks for the clarifcation!

Cheers,

- Ben

[Robert Nelson]

On Fri, Sep 12, 2014 at 4:08 PM, Ben Gamari <b...@smart-cactus.org> wrote:
> Robert Nelson <robert...@gmail.com> writes:
>
>>
>> So the "-bone" is close to mainline (small # of patches). The "-ti" we
>> are a basing on a ti branch: (git.ti.com, patchset >20Mb).. Plus the
>> 'debian' linux-image-armmp will also work once we switch to jessie..
>> (you can even install ubuntu's linux-image *.deb) the bootloader will
>> find it.
>>
>> v3.14-ti repo: https://github.com/beagleboard/linux/tree/3.14
>>

> How do you go about generating the .debs? There doesn't appear any
> packaging in the beagleboard/linux tree and the .debs don't appear to
> have corresponding source debs.

We are using the in-tree "make deb-pkg"

After i push a tag to:

https://github.com/beagleboard/linux/

Like: 3.14.17-ti-r19

https://github.com/beagleboard/linux/tree/3.14.17-ti-r19

I'll fire off a native build (wheezy *.deb is built in a clean wheezy chroot)

fakeroot make -j5 ARCH=arm LOCALVERSION=-ti-r19 CROSS_COMPILE=
KDEB_PKGVERSION=1wheezy KBUILD_DEBARCH=armhf deb-pkg

This generates:

linux-headers-3.14.17-ti-r19_1wheezy_armhf.deb
linux-image-3.14.17-ti-r19_1wheezy_armhf.deb
linux-libc-dev_1wheezy_armhf.deb

(and) (which i haven't enabled in the 3.14 branch)

linux-firmware-image-3.16.2-armv7-lpae-x2_1jessie_armhf.deb

linux-headers-*
linux-firmware-image-*
linux-image-*

get pushed to repos.rcn-ee.net (reprepro)

linux-libc-dev_1wheezy_armhf.deb -> /dev/null

So unfortunately the src package is not generated via "make deb-pkg"
thus we rely on the git tag's..

PS you can build a *.deb via cross on x86:

make -j5 ARCH=arm LOCALVERSION=-git<sha>
CROSS_COMPILE=<bin/arm-cross-> KDEB_PKGVERSION=1cross
KBUILD_DEBARCH=armhf deb-pkg

[ah...@curaoceanus.org]

I must be missing something, apt-get is not finding any of the linux-image-* files. Do I need to add a repository ?

Thanks

On Sunday, August 17, 2014 9:26:34 PM UTC-4, Jason Kridner wrote:

[Ben Gamari]

Robert Nelson <robert...@gmail.com> writes:

>
> So the "-bone" is close to mainline (small # of patches). The "-ti" we
> are a basing on a ti branch: (git.ti.com, patchset >20Mb).. Plus the
> 'debian' linux-image-armmp will also work once we switch to jessie..
> (you can even install ubuntu's linux-image *.deb) the bootloader will
> find it.
>
> v3.14-ti repo: https://github.com/beagleboard/linux/tree/3.14
>

How do you go about generating the .debs? There doesn't appear any
packaging in the beagleboard/linux tree and the .debs don't appear to
have corresponding source debs.

Cheers,

- Ben

[Ben Gamari]

Robert Nelson <robert...@gmail.com> writes:

> On Fri, Sep 12, 2014 at 4:08 PM, Ben Gamari <b...@smart-cactus.org> wrote:
>> Robert Nelson <robert...@gmail.com> writes:
>>
>>>
>>> So the "-bone" is close to mainline (small # of patches). The "-ti" we
>>> are a basing on a ti branch: (git.ti.com, patchset >20Mb).. Plus the
>>> 'debian' linux-image-armmp will also work once we switch to jessie..
>>> (you can even install ubuntu's linux-image *.deb) the bootloader will
>>> find it.
>>>
>>> v3.14-ti repo: https://github.com/beagleboard/linux/tree/3.14
>>>
>> How do you go about generating the .debs? There doesn't appear any
>> packaging in the beagleboard/linux tree and the .debs don't appear to
>> have corresponding source debs.
>
> We are using the in-tree "make deb-pkg"
>

Thanks for the thorough reply!

Cheers,

- Ben

[Robert Nelson]

On Sat, Sep 13, 2014 at 8:37 PM, <ah...@curaoceanus.org> wrote:
> I must be missing something, apt-get is not finding any of the linux-image-*
> files. Do I need to add a repository ?
> Thanks

Yeap, you didn't read the note in the second paragraph.

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-09-03

[neo]

Hi Jason

Sorry to ask again. Will PREMPT be enabled in this ?

On Monday, August 18, 2014 6:56:34 AM UTC+5:30, Jason Kridner wrote:

[Robert Nelson]

On Wed, Sep 17, 2014 at 9:53 AM, neo <prag....@gmail.com> wrote:
> Hi Jason
>
> Sorry to ask again. Will PREMPT be enabled in this ?

Full "preempt" no, not by default, but i'm testing "CONFIG_PREEMPT_VOLUNTARY"..

I'm still a little worried about the: "cost of slighly lower
throughput." for some applications we need all 1Ghz...

[Jason Kridner]

On Wed, Sep 17, 2014 at 11:13 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Wed, Sep 17, 2014 at 9:53 AM, neo <prag....@gmail.com> wrote:
>> Hi Jason
>>
>> Sorry to ask again. Will PREMPT be enabled in this ?
>
> Full "preempt" no, not by default, but i'm testing "CONFIG_PREEMPT_VOLUNTARY"..
>
> I'm still a little worried about the: "cost of slighly lower
> throughput." for some applications we need all 1Ghz...

I suspect most applications of BeagleBone Black will be more worried
about latency than throughput due to its "industrial" nature.
BeaglePilot, OpenROV, Lasersaur, MachineKit, Pocket NC, QuickBot, etc.
Sure, applications like Ninja Blocks, GrannyCam, and other "IoT"-ish
stuff might not care so much about latency, but they are probably more
interested in power management than absolutely highest performance.
Just my impression.

Would love to encourage more people to share what they are doing at
http://beagleboard.org/project and to reach out for project spotlights
on http://beagleboard.org/blog to give us all more of an impression of
what people need and are doing.

I'm more worried about if anything breaks like what the BeaglePilot
folks have been reporting about some PRU driver issues related to
PREEMPT.

I will say that simply using the RT scheduler without PREEMPT still
makes things "pretty darn fast" (TM) as can be seen in the UCSD
BeagleMIP which runs the balancing algorithm as a normal Linux thread
w/o the PRUs, kernel task or PREEMPT.

>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/
>

[neo]

Hi Robert

Ya I agree with Jason because if most of the time we are not running web servers using BBB but are interfacing BBB to the external world.
So i am more worried about latency than throughput.
Whats the risk of enabling CONFIG_PREEMPT in the kernel ?

Hi Jason, What were the issue that you mentioned were faced by BeaglePilot when using PRU ?

Thanks

[Robert Nelson]

On Thu, Sep 18, 2014 at 11:34 AM, neo <prag....@gmail.com> wrote:
> Hi Robert
>
> Ya I agree with Jason because if most of the time we are not running web
> servers using BBB but are interfacing BBB to the external world.
> So i am more worried about latency than throughput.
> Whats the risk of enabling CONFIG_PREEMPT in the kernel ?

sudo apt-get update
sudo apt-get install linux-image-3.14.19-ti-r22

has: CONFIG_PREEMPT_VOLUNTARY

In the past, preempt broke a lot of things. So i'm always hesitant to
enable it by default across the board.

>
> Hi Jason, What were the issue that you mentioned were faced by BeaglePilot
> when using PRU ?

[Charles Steinkuehler]

On 9/18/2014 11:40 AM, Robert Nelson wrote:
>
> sudo apt-get update
> sudo apt-get install linux-image-3.14.19-ti-r22
>
> has: CONFIG_PREEMPT_VOLUNTARY
>
> In the past, preempt broke a lot of things. So i'm always hesitant to
> enable it by default across the board.

PREEMPT has a tendency to tickle obscure bugs in non-SMP safe kernel
code. Many nasty bugs were uncovered as the PREEMPT code got merged
into the kernel. Now the core kernel is very SMP safe, but there are
still a lot of drivers (ie: "vendor-supplied code for single-core SoCs")
that are not SMP clean.

As multi-core ARM systems become more common, the situation should
improve (as it did with the x86 over time).

--
Charles Steinkuehler
cha...@steinkuehler.net

[neo star]

Hi Charles the BBB is a single core Soc

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/4eDQvQOkUkc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Thu, Sep 18, 2014 at 12:34 PM, neo star <prag....@gmail.com> wrote:
> Hi Charles the BBB is a single core Soc

But, what about the poor panda/am43xx users who can also use this image. ;)

[William Hermans]

Hi Charles the BBB is a single core Soc

Actually, if you want to argue about it. The BBB has 3 cores.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Charles Steinkuehler]

I realize the BBB is a single-core SoC.

My point is enabling PREEMPT code in the kernel *REQUIRES* all kernel
code to be SMP safe (even when running on a single core!), which is why
this option causes stability issues.

As for the multi-core TI chips with similar drivers, it is not uncommon
for drivers to (mostly) work in a multi-core system without *REALLY*
being SMP safe. See the history of integrating the PREEMPT patch set to
the mainline kernel for a laundry list of obscure, hard-to-trace kernel
bugs that were uncovered in the process, even though Linux had been
running on multi-core x86 systems for quite some time.

--
Charles Steinkuehler
cha...@steinkuehler.net

[neo]

Hi William

If you are counting the PRU yes, but technically they are not processors but more of peripherals/programmable controllers. Connect me if i am wrong.

[neo]

Oh i see, i didn't realize that you could use this image for panda. ok

[Robert Nelson]

On Thu, Sep 18, 2014 at 1:48 PM, neo <prag....@gmail.com> wrote:
> Hi William
>
> If you are counting the PRU yes, but technically they are not processors but
> more of peripherals/programmable controllers. Connect me if i am wrong.

There's other "processors" then the main Cortex-A8 core.. You got the
gpu and the Cortex-M3, both of which you can off load "tasks" too..
(The M3, does pm..)

[neo]

Thanks Charles for the reply.
I was trying to understand the complications of using CONFIG_PREEMPT.
But one final question, shouldn't SMP be portable across platforms be it x86 or ARM ? If so the problems should be gone right ?

[neo]

Hi William

I can understand the GPU but Cortex M3 ? Is it part of of the SOC ?
By PM did you mean Power Management ?

[Robert Nelson]

On Thu, Sep 18, 2014 at 2:07 PM, neo <prag....@gmail.com> wrote:
> Hi William
>

> I can understand the GPU but Cortex M3 ? Is it part of of the SOC ?
> By PM did you mean Power Management ?

Yeap, it's inside and you have to talk/interact (load code) on it to
do lower power management.

[John Syn]

On 9/18/14, 11:58 AM, "Robert Nelson" <robert...@gmail.com> wrote:

>On Thu, Sep 18, 2014 at 1:48 PM, neo <prag....@gmail.com> wrote:
>> Hi William
>>
>> If you are counting the PRU yes, but technically they are not
>>processors but
>> more of peripherals/programmable controllers. Connect me if i am wrong.
>
>There's other "processors" then the main Cortex-A8 core.. You got the
>gpu and the Cortex-M3, both of which you can off load "tasks" too..
>(The M3, does pm..)

Yeah, but this is all unrelated to the stability issue. When Charles talks
about SMP safe, he is really talking about re-entrant safe code. With
PREEMPT, the big kernel lock was broken up to improve the Interrupt
latency. Now drivers have to ensure that variables/structures that are
accessed from both the kernel code and interrupt context are protected or
a race condition will occur. As Charles said, some of the third party
drivers haven¹t been updated to make them safe. Most of these are fixed by
following good programming practices that kernel gatekeepers enforce, but
old drivers only get fixed when they are updated.

Regards,
John

>
>Regards,
>
>--
>Robert Nelson
>http://www.rcn-ee.com/
>

[neo]

Thanks John for the explanation

[neo]

But i am not able to find any references to it in the AM335x_TechnicalReferenceManual.

[neo]

Hi Jason

Bit confused with the naming convnsion used in the link http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
The naming conventions that i am confused with are, basically what do they mean  :

1. Flasher: (lxde)
2. microSD/Standalone: (lxde)
3. Flasher: (console: 200Mb used)
4. microSD/Standalone: (console: 200Mb used)

I understand that they have 3.14 kernel its just the naming conversion that confuses me.

[Robert Nelson]

On Thu, Sep 18, 2014 at 3:28 PM, neo <prag....@gmail.com> wrote:
> Hi Jason
>
> Bit confused with the naming convnsion used in the link
> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-08-05
> The naming conventions that i am confused with are, basically what do they
> mean :
>
> Flasher: (lxde)

On powerup it flashes eMMC with "lxde desktop", thus it'll shutdown in
15mins, and you need to remove microSD card.

> microSD/Standalone: (lxde)
Like the "flasher" above but runs from microSD

> Flasher: (console: 200Mb used)
On powerup it flashes eMMC with "base console", thus it'll shutdown in
15mins, and you need to remove microSD card.

> microSD/Standalone: (console: 200Mb used)
Like the "flasher" above but runs from microSD

> I understand that they have 3.14 kernel its just the naming conversion that
> confuses me.

Actually out of the box, they have 3.8 "installed"... it's up to you
to switch to really any..

[Víctor MV]

Hi everyone,

Thanks Jason for pointing out this thread. Let me share with you our conclusions through BeaglePilot:

• We tested vanilla, PREEMPT, RT_PREEMPT and Xenomai several times and our results indicated that the best performing one is actually the PREEMPT kernel (not the RT_PREEMPT as one would expect).
  
• We had some issues with the capemgr while working with the RT_PREEMPT (not with PREEMPT) patches but once we updated the patches (available here) we made it work with RT_PREEMPT as well.
• At the time our flying systems are running a PREEMPT Debian.

According to our benchmarking my recommendation will be to use PREEMPT because it's quite easy to activate/mantain.

I'd be happy to attend any questions on this matter. This post could be of some interest for some of you.

[neo]

Hi Robert i am guessing that the headless version is the one marked as console.

[Robert Nelson]

On Thu, Sep 18, 2014 at 3:45 PM, neo <prag....@gmail.com> wrote:
> Hi Robert i am guessing that the headless version is the one marked as
> console.

Well, it's not truly "headless" as the hdmi (tty0) interface is
active, but it's exactly the same as serial/ssh would show you for a
login.. Just no x11/lxde/wm/etc...

console... headless.. tomato/tomatO...

[neo]

Thanks Robert.

[Charles Steinkuehler]

Linux SMP *IS* portable across architectures, and *MOST* of the problems
*ARE* gone. The Linux kernel on whole is much better code than before
PREEMPT was merged.

These days problems are generally caused by ARCH and SoC specific
drivers (like HDMI, SD/eMMC, USB, etc), where the folks writing them
might not have the experience of the primary kernel maintainers. Also,
the drivers don't get near the "wringing out" of more common hardware,
so it more common to find "lurking" bugs when enabling PREEMPT.

In an ecosystem like ARM, which has mostly been single-core (until
recently) and had *LOTS* of different folks of varying ability writing
drivers, it's going to take a while before _everything_ is truly SMP
safe and you can enable PREEMPT with no more concern than you would on
an x86.

>>>> cha...@steinkuehler.net <javascript:>

>>>>
>>>> --
>>>> For more options, visit http://beagleboard.org/discuss
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>>>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/4eDQvQOkUkc/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to

>> beagleboard...@googlegroups.com <javascript:>.

>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Charles Steinkuehler

>> cha...@steinkuehler.net <javascript:>
>>
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[neo]

Hi Víctor

I was just going through https://groups.google.com/forum/#!topic/beaglepilot/7DKcdm0AEPo
But your post made a lot of thing clear. Thanks a lot.

[Charles Steinkuehler]

On 9/18/2014 3:43 PM, Víctor MV wrote:
>
> According to our benchmarking my recommendation will be to use PREEMPT
> because it's quite easy to activate/mantain.
>
> I'd be happy to attend any questions on this matter. This post

> <http://erlerobot.com/blog/beaglepilot-cyclictests-different-kernels/>

> could be of some interest for some of you.

How did you manage to get 630 uS worst-case for Xenomai? I've never
seen a worst-case above 100 uS, and IIRC it's more like 75-80 uS worst-case.

Does your stress test include heavy IRQ/DMA usage (Ethernet, uSD/eMMC,
Display) or mostly CPU load?

Regardless, it is much easier to work with PREEMPT or RT_PREEMT If those
meet your needs.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Víctor MV]

Hey Charles,

The Xenomai tests were performed at the userspace level (not even kernelspace or xenomai-kernelspace). We wanted to make a quick test and porting all the drivers to Xenomai seemed like a lot of work.

I agree with you, PREEMPT seems to us specially comfortable and easy to keep up with the changes.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/4eDQvQOkUkc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Jesse Cobra]

Earlier today I did some testing with the 3.8.13 kernel and an audio cape.

When running the alsa loop test latency.c I had much lower latency and less XRUNs with PREMPT enabled. Something like 3ms analog audio in to analog audio out versus maybe 6ms.

Thinking of upgrading to the 3.14 kernel but I was not sure if I would have any issue with the audio cape, SPI, and analog input device tree overlays...

CAPE=BB-BONE-AUDI-02,cape-bone-iio,BB-SPI1-01-00A0

On Wed, Sep 17, 2014 at 9:14 AM, Jason Kridner <jkri...@beagleboard.org> wrote:

On Wed, Sep 17, 2014 at 11:13 AM, Robert Nelson <robert...@gmail.com> wrote:

> On Wed, Sep 17, 2014 at 9:53 AM, neo <prag....@gmail.com> wrote:
>> Hi Jason
>>

>> Sorry to ask again. Will PREMPT be enabled in this ?
>
> Full "preempt" no, not by default, but i'm testing "CONFIG_PREEMPT_VOLUNTARY"..
>
> I'm still a little worried about the: "cost of slighly lower
> throughput." for some applications we need all 1Ghz...

I suspect most applications of BeagleBone Black will be more worried
about latency than throughput due to its "industrial" nature.
BeaglePilot, OpenROV, Lasersaur, MachineKit, Pocket NC, QuickBot, etc.
Sure, applications like Ninja Blocks, GrannyCam, and other "IoT"-ish
stuff might not care so much about latency, but they are probably more
interested in power management than absolutely highest performance.
Just my impression.

Would love to encourage more people to share what they are doing at
http://beagleboard.org/project and to reach out for project spotlights
on http://beagleboard.org/blog to give us all more of an impression of
what people need and are doing.

I'm more worried about if anything breaks like what the BeaglePilot
folks have been reporting about some PRU driver issues related to
PREEMPT.

I will say that simply using the RT scheduler without PREEMPT still
makes things "pretty darn fast" (TM) as can be seen in the UCSD
BeagleMIP which runs the balancing algorithm as a normal Linux thread
w/o the PRUs, kernel task or PREEMPT.

>
> Regards,
>
> --
> Robert Nelson
> http://www.rcn-ee.com/

>

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Thu, Sep 18, 2014 at 10:01 PM, Jesse Cobra <jesse...@gmail.com> wrote:
> Earlier today I did some testing with the 3.8.13 kernel and an audio cape.
>
> When running the alsa loop test latency.c I had much lower latency and less
> XRUNs with PREMPT enabled. Something like 3ms analog audio in to analog
> audio out versus maybe 6ms.
>
> Thinking of upgrading to the 3.14 kernel but I was not sure if I would have
> any issue with the audio cape, SPI, and analog input device tree overlays...
>
> CAPE=BB-BONE-AUDI-02,cape-bone-iio,BB-SPI1-01-00A0

Well, the audio works, spi1 should.. iio, i can look at trying tomorrow..

If you want to atleast test spi1, that would be aweome..

just:

sudo apt-get update
sudo apt-get install linux-image-3.14.19-ti-r23

Then following these instructions:
http://elinux.org/Beagleboard:Capes_3.8_to_3.14#Custom_dtb

Disable:
#include "am335x-boneblack-nxp-hdmi-audio.dtsi" -> /* #include
"am335x-boneblack-nxp-hdmi-audio.dtsi" */

Enable:
#include "am335x-boneblack-nxp-hdmi-no-audio.dtsi"

Enable: spi1 or spi1a
#include "am335x-bone-spi1-spidev.dtsi"
or
#include "am335x-bone-spi1a-spidev.dtsi"

Enable: audio:
#include "am335x-bone-audio.dtsi"

make
sudo make install
sudo reboot

Note, we changed a couple things underneath, so we might have to fix a
couple "pinmux" dmesg errors..

[neo]

Hi

Is it possible to maintain an experimental branch having CONFIG_PREEMPT ?
Considering profiling shared by Víctor and the kind of projects people use BBB for ...

On Friday, September 19, 2014 2:13:21 AM UTC+5:30, Víctor MV wrote:

[abf...@gmail.com]

Why are the qmi drivers not included in the kernel or as modules in the package?