Worth buying a BBB? What to do with it?

GoogleGroups
1

Dear Community,

I am new regarding ARM based computers, and also new to Linux.

Since the RPI came out I am fascinated by the small computers, helping me to do some stuff or just doing some amazing projects with them.

Now, there is nothing really useful I could do with such a computer. I don’t need a NAS, I don’t need a webserver, nothing to do with it. The only thing I could think of is a “Upload-BBB”, which uploads my Videos on youtube (since I upload 1 video a day it could be useful).

But to be honest, every Arduino board or the Rpi would be able to do it. Other things are to boring. Just seeing the BBB working as a webserver is too boring. I want to do something very special with my BBB, if I buy one. Even LED-controlling is to boring for me.

A dream of myself is building a small flight computer, since I am a glider pilot. It should be something like a computer working with XCSoar (they already installed it on Rpi’s), plus a system showing me some information, like a digital variometer or something.

Since the BBB needs only 2.3 Watts (Rpi needs 3.5??) it would be the first beginning for my project.

I am new to Linux and programming of such computers. I have some basic programming knowledge, already worked with impactjs. If possible, I would highly prefer to programm with java, since it would not mean to learn a new language.

My friends always tell me to start with a Rpi, because of the huge community. But I see advantages in the BBB, not just because of the lower power consumption but also because of the small price for alot of power. (Cubieboard, UDOO and all that stuff is too expensive for me to start).

Do you think buying a BBB would be the best solution? Do you think as a beginner I am able to understand how to use the board?
I am willing to learn. I would start with the Youtube-upload thing and then probably try to build my flight computer.

Are there some great projects I have to see?

Thanks for your advise

regards
Starr

2

You are a great prospect to do something interesting with a Beaglebone
because you have a specific application. I quite agree with you that
getting a BBB to blink LEDs or serve web pages is not that
exciting---but it probably is a good exercise for familiarizing
yourself with the system, especially if you never used Linux or
embedded systems like BBB before. Just like flying, you have to start
with simple things before you do aerobatics.

Regarding a choice between RPI and BBB, I think people overstate the
differences between them. They both run Debian Linux derivatives, and
software should port between them just fine. Yes, there may be more
software built specifically for RPi, but if you limit yourself to
pre-baked software in this way, I don't think there's a lot of novel
stuff that can be done with it---most interesting applications involve
some sort of porting anyway. As far as I am concerned, both RPi and
BBB are interesting but RPi has an older and slower processor that is
a little bit of a dead end in terms of architectural support. It also
lacks the cool PRU unit, resulting in great flexibility and speed of
GPIO on BBB. Finally, the graphics acceleration on RPi is quite
proprietary although the BBB situation isn't that great yet,
either---although it's expected to improve any time now.

3

How would one find out about the state of accelerated graphics on the
bbb? I'm particular interested in running wayland with 3d acceleration
on the bbb. I'd love to hear that the work was being upstreamed and
make easy (at least easy w.r.t. people that know about this stuff) to
consume and use.

Chris

4

How would one find out about the state of accelerated graphics on the
bbb? I'm particular interested in running wayland with 3d acceleration
on the bbb. I'd love to hear that the work was being upstreamed and
make easy (at least easy w.r.t. people that know about this stuff) to
consume and use.

All the pieces are there for you..

We have sgx 3d graphics working with qt 5.1 (with v3.8.x/v3.12.x/etc)

The 5.01.00.01 supports egl
http://processors.wiki.ti.com/index.php/RN_5_01_00_01#Khronos_API_support

in "jessie" we have wayland 1.5.0

https://packages.debian.org/jessie/libwayland-dev

I've started a "base" rootfs here:

./RootStock-NG.sh -c bb.org-debian-testing

I started a topic here:

https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/YVRQ__e-Di4J

Just looking for like minded ideas at this point. :wink:

Regards,

5

I appreciate the response, there isn't much good detail on this stuff
on the web. I'd love to see a page on elinux.org or somewhere that
covered the state of the union and the next steps.

I agree that having sgx support is a pretty critical feature and it
seems like Jason K. is going in the right direction to port things
foward.

We are using Yocto builds here but I think meta-beaglebone is using a
3.8 kernel which is too old for the TI graphics support.

From a wishlist perspective it seems like we would want:

- TI sgx support upstreamed to kernel.org (is this ongoing?)
- Cape manager support in 3.14+

The overall goal is a yocto build for the bbb with wayland 1.5 (recipe
was added last week) and 3d acceleration.

I mentioned in another post but I'll mention it here because you were
kind enough to respond, the company I work for is using the bbb in a
product. As such it is important for us to have these features. We'd
be willing to help, either in terms of sw engineering time, or
sponsoring some of these efforts. We aren't experts yet but given some
guidance I think we could contribute. If this sounds interesting
please let me know.

Chris

6

I appreciate the response, there isn't much good detail on this stuff
on the web. I'd love to see a page on elinux.org or somewhere that
covered the state of the union and the next steps.

I agree that having sgx support is a pretty critical feature and it
seems like Jason K. is going in the right direction to port things
foward.

We are using Yocto builds here but I think meta-beaglebone is using a
3.8 kernel which is too old for the TI graphics support.

From a wishlist perspective it seems like we would want:

- TI sgx support upstreamed to kernel.org (is this ongoing?)

www.imgtec.com will never allow that to happen. The biggest blocker
for using the "blob" was the soc reset patchset, which looks like to
hit v3.16-rc0, i back ported that from ti's 3.12 to make it work for
our self.

- Cape manager support in 3.14+

patches welcome.. It looks like there is a "chance" overlays might get
accepted in v3.16-rc0, not holding my breath.

The overall goal is a yocto build for the bbb with wayland 1.5 (recipe
was added last week) and 3d acceleration.

I mentioned in another post but I'll mention it here because you were
kind enough to respond, the company I work for is using the bbb in a
product. As such it is important for us to have these features. We'd
be willing to help, either in terms of sw engineering time, or
sponsoring some of these efforts. We aren't experts yet but given some
guidance I think we could contribute. If this sounds interesting
please let me know.

Regards,

7

I appreciate the response, there isn't much good detail on this stuff
on the web. I'd love to see a page on elinux.org or somewhere that
covered the state of the union and the next steps.

I agree that having sgx support is a pretty critical feature and it
seems like Jason K. is going in the right direction to port things
foward.

We are using Yocto builds here but I think meta-beaglebone is using a
3.8 kernel which is too old for the TI graphics support.

bb-kernel/patches/sgx at am33x-v3.8 · RobertCNelson/bb-kernel · GitHub

Is this something that should make its way into meta-beaglebone?

From a wishlist perspective it seems like we would want:

- TI sgx support upstreamed to kernel.org (is this ongoing?)

www.imgtec.com will never allow that to happen. The biggest blocker
for using the "blob" was the soc reset patchset, which looks like to
hit v3.16-rc0, i back ported that from ti's 3.12 to make it work for
our self.

Certainly using a binary driver is a tolerable thing if its easily
buildable and shippable with the product.

- Cape manager support in 3.14+

patches welcome.. It looks like there is a "chance" overlays might get
accepted in v3.16-rc0, not holding my breath.

I don't think we know enough here to be able to jump in from zero to
help out. Would need a bit more direction or specific tasks to work on
in order to be able to be productive. If you or anyone else is up for
providing more direction please drop me an email.

Chris

8

I don’t understand why people want to take control over everything, like they really understand what’s going on in these huge sources. All wireless (and not only) firmware is provided in binaries and nobody cares. Just accept that some proprietary software is available in a binary state.

9

I concur. I was simply referring to being able to load a module or a
firmware blob on a stock kernel and be ready to go vs. custom patches
against someone's branch of the kernel plus a module and firmware
blob.

Chris

10

I appreciate the response, there isn't much good detail on this stuff
on the web. I'd love to see a page on elinux.org or somewhere that
covered the state of the union and the next steps.

I agree that having sgx support is a pretty critical feature and it
seems like Jason K. is going in the right direction to port things
foward.

We are using Yocto builds here but I think meta-beaglebone is using a
3.8 kernel which is too old for the TI graphics support.

bb-kernel/patches/sgx at am33x-v3.8 · RobertCNelson/bb-kernel · GitHub

Is this something that should make its way into meta-beaglebone?

Sure.. They can pull what they need from:

too.. :wink:

I still maintain that legacy repo from them, so if they don't pull it
in.. well...

From a wishlist perspective it seems like we would want:

- TI sgx support upstreamed to kernel.org (is this ongoing?)

www.imgtec.com will never allow that to happen. The biggest blocker
for using the "blob" was the soc reset patchset, which looks like to
hit v3.16-rc0, i back ported that from ti's 3.12 to make it work for
our self.

Certainly using a binary driver is a tolerable thing if its easily
buildable and shippable with the product.

- Cape manager support in 3.14+

patches welcome.. It looks like there is a "chance" overlays might get
accepted in v3.16-rc0, not holding my breath.

I don't think we know enough here to be able to jump in from zero to
help out. Would need a bit more direction or specific tasks to work on
in order to be able to be productive. If you or anyone else is up for
providing more direction please drop me an email.

Well, until "overlays" hit upstream, right now it's like herding cats.. :wink:

Regards,

11

If the "binaries" is available, and actively supported, well that's
totally different.

But then you have something like the omap4.

Regards,

12

Ahh.

Do you ever work with Koen, the maintainer of the meta-beaglebone repository?

Chris

13

Sure.. They can pull what they need from:

GitHub - beagleboard/kernel at 3.8

too.. :wink:

I still maintain that legacy repo from them, so if they don't pull it
in.. well...

Ahh.

Do you ever work with Koen, the maintainer of the meta-beaglebone repository?

So that's the repo Koen and I shared... However, he left CircuitCo for
Linaro. I don't know if he's interested in working on beagle stuff
again on his 'free' time.

Regards,

14

Wow - SGX mostly works now? Sweet. Guess I’ll have to play around with it =P. Does it interface natively with the GLX? Or do we have to do something stupid like with the RPi and use an RPi specific renderer setup?

  • Nathaniel Lewis
15

Just via EGL, with QT.

Regards,