GSoC 2013 ideas

Let's make a killer ideas page for our application this year!

I believe it is really important for us to focus on advancing the
state for all players, but anything open source where we have some
good mentorship to provide should be appealing. Let's make it clear
that BeagleBoard.org has the best mentors in the open source world!

I see our contributions breaking down in these key categories:
Home manufacturing: CNC, 3D printers, Laser cutters, pick-and-place
Drones/bots: frameworks like ROS, vision like OpenCV, autopilot, video streaming
Kernel work for embedded: dynamic device tree overlays, updated
"lshw", asymmetric multiprocessor support
Odd-ball co-processor support (what is a better name?): GCC for
C6000/PRU, dsp-run-style library abstracts messaging through STDIO in
GCC library, PRU in Bonescript
High-level language physical computing: Bonescript, PyBBIO, etc.

What other key categories do you see and how else would you categorize
the above?

Please let me know if you are interested in being a mentor for GSoC 2013!

Also, I second Jason's enthusiasm behind making a killer idea page for this year. Do any of you have any thoughts regarding the categories Jason proposed? We're thinking:

Home manufacturing: CNC, 3D printers, Laser cutters, pick-and-place
Drones/bots: frameworks like ROS, vision like OpenCV, autopilot, video streaming Kernel work for embedded: dynamic device tree overlays, updated "lshw", asymmetric multiprocessor support Odd-ball co-processor support (what is a better name?): GCC for C6000/PRU, dsp-run-style library abstracts messaging through STDIO in GCC library, PRU in Bonescript High-level language physical computing: Bonescript, PyBBIO, etc.

What other key categories do you see and how else would you categorize the above?

Thanks!
Jessica

Please add your project ideas to the project idea wiki page! It's important for us to have a killer ideas page to be accepted this year. The goal is to have the page updated by March 22.

http://elinux.org/BeagleBoard/GSoC/Ideas

The idea is that the ideas page will break down in these key categories:
Home manufacturing: CNC, 3D printers, Laser cutters, pick-and-place
Drones/bots: frameworks like ROS, vision like OpenCV, autopilot, video streaming Kernel work for embedded: dynamic device tree overlays, updated "lshw", asymmetric multiprocessor support Odd-ball co-processor support (what is a better name?): GCC for C6000/PRU, dsp-run-style library abstracts messaging through STDIO in GCC library, PRU in Bonescript High-level language physical computing: Bonescript, PyBBIO, etc.

What other key categories do you see and how else would you categorize the above?

We need new ideas up on the idea page by tomorrow! It's important for us to have an impressive ideas page to be accepted this year. http://elinux.org/BeagleBoard/GSoC/Ideas

Potential key categories:
Home manufacturing: CNC, 3D printers, Laser cutters, pick-and-place
Drones/bots: frameworks like ROS, vision like OpenCV, autopilot, video streaming Kernel work for embedded: dynamic device tree overlays, updated "lshw", asymmetric multiprocessor support Odd-ball co-processor support (what is a better name?): GCC for C6000/PRU, dsp-run-style library abstracts messaging through STDIO in GCC library, PRU in Bonescript High-level language physical computing: Bonescript, PyBBIO, etc.

Does anyone see any other key categories or a different way of categorizing the ones listed above?

Anyone have anything for the ideas page? We haven't seen much input yet and the Friday deadline is quickly approaching.

http://elinux.org/BeagleBoard/GSoC/Ideas

Thanks!
Jessica

I have one idea that at least I think would be fairly useful. I would gladly mentor for it. It’s more build system / kernel / low-level stack oriented than Beagle-specific. However, the beagle would be an excellent platform for prototyping.

Modify the Android build system, libc and kernel to work with FatELF binaries.

Thoughts?

C



From: Callaway, Jessica
Sent: Monday, March 25, 2013 2:23 PM
To: beagleboard-gsoc@googlegroups.com
Reply To: beagleboard-gsoc@googlegroups.com
Subject: [beagleboard-gsoc] RE: GSoC 2013 ideas

Anyone have anything for the ideas page? We haven’t seen much input yet and the Friday deadline is quickly approaching.

http://elinux.org/BeagleBoard/GSoC/Ideas

Thanks!
Jessica

See http://icculus.org/fatelf/

The FatELF code is BSD licensed, which means it could be included /
modified freely in Android.

Specifically, I would suggest to make an "architecture-independent"
FatELF userspace work on 2 architectures: i386 and ARMv7a (e.g.
BeagleBoard-xM), including platform-specific libraries required for
hardware acceleration and userspace drivers.

Everything below and including the kernel (kernel & bootloaders) would
remain architecture-specific.

1) A fair bit of the Android build system would need to be modified, including
  a) a configuration parameter, listing "target" architectures
  b) integrate FatELF utils into the Android build system
  c) an extra stage at the end that would merge the /system
directories for two architectures into one using fatelf-glue
2) Bionic's dynamic loader would need to be modified.
3) The Linux kernel would need to include the latest FatELF patch

C

Anybody? ... +Jason Kridner?

I have one idea that at least I think would be fairly useful. I would
gladly mentor for it. It's more build system / kernel / low-level stack
oriented than Beagle-specific. However, the beagle would be an excellent
platform for prototyping.

Modify the Android build system, libc and kernel to work with FatELF
binaries.

Thoughts?

I think that'd be very useful if it enables a combination of armv7-neon-vfp
(or whatever it is called) and hard-float binaries. Not sure why just
Android and not OE. Generally, I think supporting FatELF anywhere is
helpful.

Any chance you'd also be willing to mentor someone trying to reproduce the
AI Super-Jumbo demo of having Android in a virtual terminal at the same
time as Ubuntu and/or Angstrom?

Anybody? ... +Jason Kridner?

Sorry, I was slow on the draw there. This mailing list fell out of my
priority inbox due to a lack of activity. It is now back on top. :slight_smile:

> See FatELF
>
> The FatELF code is BSD licensed, which means it could be included /
> modified freely in Android.
>
> Specifically, I would suggest to make an "architecture-independent"
> FatELF userspace work on 2 architectures: i386 and ARMv7a (e.g.
> BeagleBoard-xM), including platform-specific libraries required for
> hardware acceleration and userspace drivers.

Makes sense.

>
> Everything below and including the kernel (kernel & bootloaders) would
> remain architecture-specific.
>
> 1) A fair bit of the Android build system would need to be modified,
including
> a) a configuration parameter, listing "target" architectures
> b) integrate FatELF utils into the Android build system
> c) an extra stage at the end that would merge the /system
> directories for two architectures into one using fatelf-glue
> 2) Bionic's dynamic loader would need to be modified.
> 3) The Linux kernel would need to include the latest FatELF patch

Yeah, I think it is useful, even though it helps out Intel probably more
than ARM/TI/Beagle. Again, I'd be somewhat more interested in seeing FatELF
support brought into OE or work across ARM ABIs, but I'm happy to simply
see support for it increased and we need to make sure mentors are able and
anxious to support the proposed ideas.

chrisfriedt@gmail.com writes:

I have one idea that at least I think would be fairly useful. I would
gladly mentor for it. It's more build system / kernel / low-level stack
oriented than Beagle-specific. However, the beagle would be an excellent
platform for prototyping.
Modify the Android build system, libc and kernel to work with FatELF
binaries.

Thoughts?

Fatelf is one of the worst ideas ever suggested and was quickly
dismissed on lkml. We should not go there.

chrisfriedt@gmail.com writes:

> I have one idea that at least I think would be fairly useful. I would
> gladly mentor for it. It's more build system / kernel / low-level stack
> oriented than Beagle-specific. However, the beagle would be an excellent
> platform for prototyping.
> Modify the Android build system, libc and kernel to work with FatELF
> binaries.
>
> Thoughts?

Fatelf is one of the worst ideas ever suggested and was quickly
dismissed on lkml. We should not go there.

Any quick pointers on the best long-winded dismissals of it? I find it
Universal Binaries helpful on OS X.

@Mans, the _main_ reason that FatELF was dismissed in the LKML is
because they posted a patch that would also allow kernel _modules_ to
be in FatELF format... that would just be fugly... really little to do
with userspace. I completely agree that the kernel and all modules
should be compiled in regular-elf format.

However, there was also a patch included that would allow the kernel
to parse and execute FatELF binaries / link FatELF .so's in to a
process, which is incredibly useful, is what I was actually hinting
at, and is what Jason sees to be A Good Thing™ on Mac OS X.

Personally, I feel that FatELF support would be a _HUGE_ plus for
Android, and I've even approached Google about it. Most of their code
runs in a VM... Jalvik has historically had the mantra "Write Once,
Run Anywhere". This would really make that mantra true, since it would
cover the JNI layer as well. Plus, having a lovely kernel like Linux
with a more-or-less architecture-agnostic HAL makes things even more
portable :wink:

@Jason - I agree about the ARM ABI comments. Actually, that would be a
fantastic augmentation of the FatELF standard that would be really
beneficial.

0) ARM ISA / ABI fixups for FatELF ?

C

Jason Kridner <jkridner@gmail.com> writes:

chrisfriedt@gmail.com writes:

> I have one idea that at least I think would be fairly useful. I would
> gladly mentor for it. It's more build system / kernel / low-level stack
> oriented than Beagle-specific. However, the beagle would be an excellent
> platform for prototyping.
> Modify the Android build system, libc and kernel to work with FatELF
> binaries.
>
> Thoughts?

Fatelf is one of the worst ideas ever suggested and was quickly
dismissed on lkml. We should not go there.

Any quick pointers on the best long-winded dismissals of it?

Alan Cox gives it short shrift: https://lkml.org/lkml/2009/11/2/372

I find it Universal Binaries helpful on OS X.

That's probably because software distribution on osx (as on most
user-oriented systems) is a shambles.

Well... users _are_ kind of shambley... yes, though, I agree... the
Mac OS X people are definitely doing some things wrong.

Any other ideas to contribute? We are submitting tomorrow afternoon.

What else can you come up with in the next 24 hours?

Hi! Are we still on schedule for proposing ideas?

I think we can keep editing the ideas page to help clarify the projects and to help students improve their proposals. Project proposals must be submitted by May 3.