BeagleBoard software design competition #1 to give away a Rev C prototype the first week of January

GoogleGroups
1

Koen, Steve, Dirk, Robert, Hunyue, and Mans,

Thank you each for volunteering to be judges for this first BeagleBoard software design contest. I'd like to give away a Rev C prototype during the first full week in January, so we must act quickly. The first prototypes are being tested out by Steve this week and the USB EHCI port is working. It will still be March by the time the boards are available to purchase, so I believe this will be a special treat for whoever wins.

As we discussed on the IRC channel[1], I have created a wiki page to collect our thoughts[2].

I believe our first steps are:
* All the judges are to review the rules, reply to this e-mail with comments, and edit the rules for language where appropriate.
* All the judges are to add qualifying (required) and rating (desired) criteria to the wishlist. Let's try to finish that by Saturday so that we can begin to work on selecting the criteria. This is a place for raw ideas.

I expect the #1 question from the overall community will be "when will the contest be defined?" Let's work quickly to give the participants as much time as possible to work on their projects.

Let's get the rules and criteria down first, then we can work on logistics. Certainly creating entries at http://beagleboard.org/project makes sense to me. We can possibly use the wiki, however, to make it clear who has actually entered the contest. Hopefully write protection isn't required and it will be enough to simply track who made any changes.

Thanks for the participation from each of you!

Regards,
Jason

[1] http://www.beagleboard.org/irclogs/index.php?date=2008-12-18#T18:40:58
[2] http://elinux.org/BeagleBoard/contest

2

I think we should add all entries should be required to at least include a
hint or a clue as to what the entry should do. Might be just a sentence.

Also, in light of some of the things seen with the SD card images, a tarball
of the contents (one tar per partition) would be highly desireable.

As an alternative to the SD image, I think we should also allow for an
alternative entry format with tarballs + JFFS2 images + instructions for
flashing into NAND. This would allow for entries that would use the SD slot
as removeable media. The flip side is any image that fails to flash with the
provided instructions would be a disqualification. :wink:

Addition item suggested for the desireable (I can add it if there are no
objections) -
A working USB TV tuner. The one I know that works with Linux is the original
Hauppauge HVR950. Only problem with this tuner (and possibly other tuner) is
the OSI open source rule might be violated as this requires a firmware file
that needs to be downloaded. The other complication here is this unit is ATSC
which makes it North America-centeric.

The proposal is not necessarily for that particular unit but a working Digital
USB TV tuner. Could be DVB-T but someone else will have to judge that.

With something like this working, the next buld up would be an image to turn
the beagle + pico into a projection TV. This part is likely to involve
getting a DSP CODEC to decode the MPEG streams.

Going further in this is to have LIRC working.

Additional comments for the "stable MUSB" desireable -
When I brought it up, what I had in mind was having MUSB work well with a
variety of GSPCA driver webcam. They seem to be rather common with the low
end cameras. Specific symptoms I have noticed are:
Using the same driver, I can have one camera working consistantly. A second
camera using the same driver working sometimes. A third camera not working at
all. When it fails to work, there appears to be an issue with enumeration. I
think Koen has seen enumeration issues with a camera he's tried.

The hot plug issue with MUSB is simply being able to plug a variety of things
into a hub with a A cable after boot and expecting it to work. In addition,
changing from and A cable to a B cable should also just work. This sometimes
works but not all ways.

3

I think we should add all entries should be required to at least
include a
hint or a clue as to what the entry should do. Might be just a
sentence.

Also, in light of some of the things seen with the SD card images, a
tarball
of the contents (one tar per partition) would be highly desireable.

I'm still hopeful that 'dd' images can be written with just about any
host machine OS and be bootable. Care would need to be taken to
ensure they fit onto all 1GB SD cards.

As an alternative to the SD image, I think we should also allow for an
alternative entry format with tarballs + JFFS2 images + instructions
for
flashing into NAND. This would allow for entries that would use the
SD slot
as removeable media. The flip side is any image that fails to flash
with the
provided instructions would be a disqualification. :wink:

I'd like for the instructions to be something that someone with a
Windows or Mac OS X host could follow, but I could be in the minority
in this group on this thinking. Perhaps we should put both 'dd'
options and instruction-based options in the wishlist and vote on each?

Addition item suggested for the desireable (I can add it if there
are no
objections) -
A working USB TV tuner. The one I know that works with Linux is the
original
Hauppauge HVR950. Only problem with this tuner (and possibly other
tuner) is
the OSI open source rule might be violated as this requires a
firmware file
that needs to be downloaded. The other complication here is this
unit is ATSC
which makes it North America-centeric.

Put it on the wishlist and we'll approve/disapprove each of the items
on the wishlist.

4

....snip....

> As an alternative to the SD image, I think we should also allow for an
> alternative entry format with tarballs + JFFS2 images + instructions
> for
> flashing into NAND. This would allow for entries that would use the
> SD slot
> as removeable media. The flip side is any image that fails to flash
> with the
> provided instructions would be a disqualification. :wink:

I'd like for the instructions to be something that someone with a
Windows or Mac OS X host could follow, but I could be in the minority
in this group on this thinking. Perhaps we should put both 'dd'
options and instruction-based options in the wishlist and vote on each?

Either way. I just think it would be nice to be able to use the internal flash
in a project. The instructions should something along the lines of - copy
files onto flash card. Invoke U-boot incantations to flash it onto NAND. This
should be largely OS agnostic. The instructions would be the magic numbers
used for the nand write.

> Addition item suggested for the desireable (I can add it if there
> are no
> objections) -
> A working USB TV tuner. The one I know that works with Linux is the
> original
> Hauppauge HVR950. Only problem with this tuner (and possibly other
> tuner) is
> the OSI open source rule might be violated as this requires a
> firmware file
> that needs to be downloaded. The other complication here is this
> unit is ATSC
> which makes it North America-centeric.

Put it on the wishlist and we'll approve/disapprove each of the items
on the wishlist.

Updated wiki wishlist.

> The proposal is not necessarily for that particular unit but a
> working Digital
> USB TV tuner. Could be DVB-T but someone else will have to judge that.
>
> With something like this working, the next buld up would be an image
> to turn
> the beagle + pico into a projection TV. This part is likely to involve
> getting a DSP CODEC to decode the MPEG streams.
>
> Going further in this is to have LIRC working.
>
> Additional comments for the "stable MUSB" desireable -
> When I brought it up, what I had in mind was having MUSB work well
> with a
> variety of GSPCA driver webcam. They seem to be rather common with
> the low
> end cameras. Specific symptoms I have noticed are:
> Using the same driver, I can have one camera working consistantly. A
> second
> camera using the same driver working sometimes. A third camera not
> working at
> all. When it fails to work, there appears to be an issue with
> enumeration. I
> think Koen has seen enumeration issues with a camera he's tried.
>
> The hot plug issue with MUSB is simply being able to plug a variety
> of things
> into a hub with a A cable after boot and expecting it to work. In
> addition,
> changing from and A cable to a B cable should also just work. This
> sometimes
> works but not all ways.
>

....snip....

5

Jason Kridner <jkridner@beagleboard.org> writes:

Koen, Steve, Dirk, Robert, Hunyue, and Mans,

Thank you each for volunteering to be judges for this first
BeagleBoard software design contest. I'd like to give away a Rev C
prototype during the first full week in January, so we must act
quickly. The first prototypes are being tested out by Steve this week
and the USB EHCI port is working. It will still be March by the time
the boards are available to purchase, so I believe this will be a
special treat for whoever wins.

As we discussed on the IRC channel[1], I have created a wiki page to
collect our thoughts[2].

I believe our first steps are:
* All the judges are to review the rules, reply to this e-mail with
comments, and edit the rules for language where appropriate.
* All the judges are to add qualifying (required) and rating (desired)
criteria to the wishlist. Let's try to finish that by Saturday so
that we can begin to work on selecting the criteria. This is a place
for raw ideas.

I expect the #1 question from the overall community will be "when will
the contest be defined?" Let's work quickly to give the participants
as much time as possible to work on their projects.

I will be away from the Internet for most of the weekend. I'll catch
up with email as soon as I can.

Let's get the rules and criteria down first, then we can work on
logistics. Certainly creating entries at http://beagleboard.org/
project makes sense to me. We can possibly use the wiki, however, to
make it clear who has actually entered the contest. Hopefully write
protection isn't required and it will be enough to simply track who
made any changes.

What we have on the wiki right now can be broken down in three
categories:

1. Absolute requirements for validity of a submission.
2. Factors by which submissions will be judged.
3. Random project ideas.

The first two need to be made crystal-clear for obvious reasons, and
the second is particularly sketchy at the moment.

Some ideas to get contestants started is naturally good, but never
underestimate people's creativity.

Thinking about rating criteria, the most important to me in a context
like this are the "wow" factor and the overall quality of the
submission. Exactly what it does is less important in my view. I
would also like an emphasis on projects that allow the Beagle to
shine, not merely also-can type things.

6

Dirk and I have tried to simplify things a bit. Rather than try to get very complicated with things up-front, let's start collecting entries NOW on the wiki page[1].

Instead of having a specific point system, the judges should merely try to inform the contestants as well as possible via the wiki page[1] of what things they'd like to see. Each judge will provide 10 votes and the contestant with the most votes will win. For any tie-breaker votes, judges will only get 1 vote. I'll appreciate your help in updating the page to reflect answers to the questions asked to you about the contest.

All, please post your entries on the wiki[1] and record the projects on the BealgeBoard.org project page[2]. If you have any questions, please reply to this e-mail.

Regards,
Jason

[1] http://elinux.org/BeagleBoard/contest
[2] http://beagleboard.org/project

7

As you should know, there is an on-going BeagleBoard software design
contest. There are currently 5 entries listed[1].

Currently my favorite is qemu-omap3[2]. I have seen some real useful
progress in this project and there is a reasonably high degree of
complexity. Still, I'm very anxious to see more entries with code
running on the board.

My second favorite is BeagleRC[4]. It does show code and even
hardware running with the board. I haven't seen schematics yet. I
also haven't seen source code for the host side yet. Having some GUI
controls would be nice to avoid buying extra hardware. Output could
also be redirected to the LEDs for the purpose of demonstrations
without extra hardware. Also, if this one wins, perhaps the host
could become the new BeagleBoard. :slight_smile:

I've seen some other good video demos of possible entries, but they
haven't yet signed-up. There are also some good entries that haven't
yet provided links to code.

There are definitely some negatives to having a design contest,
including the fact that most of the great BeagleBoard developers might
never be recognized by winning it.

Sill, I encourage you to enter the contest[1] and also create a
project entry[2]. Even if you don't win the contest this time or the
project you want to submit is not yet complete, I believe we will let
these entries roll-forward to future giveaways and it will help bring
publicity to your project.

Mans, Koen, Steve, Robert,

[1] http://elinux.org/BeagleBoard/contest
[2] http://elinux.org/BeagleBoard/contest#qemu-omap3
[3] http://beagleboard.org/project
[4] http://elinux.org/BeagleBoard/contest#BeagleRC

8

As you should know, there is an on-going BeagleBoard software design
contest. There are currently 5 entries listed[1].

Currently my favorite is qemu-omap3[2]. I have seen some real useful
progress in this project and there is a reasonably high degree of
complexity. Still, I'm very anxious to see more entries with code
running on the board.

My second favorite is BeagleRC[4]. It does show code and even
hardware running with the board. I haven't seen schematics yet. I
also haven't seen source code for the host side yet. Having some GUI
controls would be nice to avoid buying extra hardware. Output could
also be redirected to the LEDs for the purpose of demonstrations
without extra hardware. Also, if this one wins, perhaps the host
could become the new BeagleBoard. :slight_smile:

I've seen some other good video demos of possible entries, but they
haven't yet signed-up. There are also some good entries that haven't
yet provided links to code.

There are definitely some negatives to having a design contest,
including the fact that most of the great BeagleBoard developers might
never be recognized by winning it.

Sill, I encourage you to enter the contest[1] and also create a
project entry[2]. Even if you don't win the contest this time or the
project you want to submit is not yet complete, I believe we will let
these entries roll-forward to future giveaways and it will help bring
publicity to your project.

Mans, Koen, Steve, Robert,

A little fast with the send button.

Mans, Koen, Steve, Robert, Hunyue, Dirk,

Do any of you have thoughts on the current entries and when we should
take our vote for the first give-away?

9

> As you should know, there is an on-going BeagleBoard software design
> contest. There are currently 5 entries listed[1].
>
> Currently my favorite is qemu-omap3[2]. I have seen some real useful
> progress in this project and there is a reasonably high degree of
> complexity. Still, I'm very anxious to see more entries with code
> running on the board.
>
> My second favorite is BeagleRC[4]. It does show code and even
> hardware running with the board. I haven't seen schematics yet. I
> also haven't seen source code for the host side yet. Having some GUI
> controls would be nice to avoid buying extra hardware. Output could
> also be redirected to the LEDs for the purpose of demonstrations
> without extra hardware. Also, if this one wins, perhaps the host
> could become the new BeagleBoard. :slight_smile:
>
> I've seen some other good video demos of possible entries, but they
> haven't yet signed-up. There are also some good entries that haven't
> yet provided links to code.
>
> There are definitely some negatives to having a design contest,
> including the fact that most of the great BeagleBoard developers might
> never be recognized by winning it.
>
> Sill, I encourage you to enter the contest[1] and also create a
> project entry[2]. Even if you don't win the contest this time or the
> project you want to submit is not yet complete, I believe we will let
> these entries roll-forward to future giveaways and it will help bring
> publicity to your project.
>
> Mans, Koen, Steve, Robert,

A little fast with the send button.

Mans, Koen, Steve, Robert, Hunyue, Dirk,

Do any of you have thoughts on the current entries and when we should
take our vote for the first give-away?

Appologies in advance if I sound a bit negative. I do not mean to discourage.

The QEMU one sounds interesting but I have doubts that it will be really
demo-able by the contest deadline. I'd be pretty impressed if the modified
qemu can boot even a stripped down uImage from a Beagle board.

The BeagleRC looks the furtherest along. About the only thing that would
make it my absolute favorite of the entries listed is if there is a
discussion or some kind of demo/analysis of worse case situations. i.e. what
if the wifi side dies or if there is a lot of interference. Basically,
it _seems_ to not address some of the reasons why people would use RT for
similar things.

The RT project looks interesting but it seems very ambitious. Would like to
see more details. Stats on number of bugs found and the types of bugs would
make more interesting to me.

The Conferencing entry would be very nice if a demo is available by the
date. I see a lot of hurdles but nothing that would completely prevent
a demo.

It looks like the entries could use a few more days. Nice projects but
I think a snapshot showing what is working now should be provided with
each entry.

10

Hi Hunyue,

I am the developer of qemu-omap3.
Actually, x-loader/uboot/linux can boot successfully and load the file
system from nand flash.

http://vm-kernel.org/blog/2008/12/15/linux-is-running-on-qemu-omap3/

MMC emulation is in progress.

11

Mans, Steve, Dirk, Koen, Hunyue, Robert,

Any thoughts on how/when to conclude this round? Then, perhaps we can
have a project-of-the-month in the future?

Regards,
Jason

12

Mans, Steve, Dirk, Koen, Hunyue, Robert,

Any thoughts on how/when to conclude this round? Then, perhaps we can
have a project-of-the-month in the future?

Let's evaluate the current submissions after the weekend and decide on a timeframe based on the outcome of the evaluations. Does that sound good?

regards,

Koen

13

Hello, I haven't checked this site in a while, and I am happily
surprised to see people discussing my project (BeagleRC).

Hunyue: You are 100% correct I do not address loss of connectivity,
and unfortunately I have had not had any time to work on it since I
posted it to the contest site. However loss of connectivity could be
detected in many ways, for example with a periodic ping/ack message
sequence. For example every 5ms host sends a ping, and gets an ack
from the beagle. If the beagle misses say 2 pings in a row then it
could move all servos to neutral. If the host misses 2 acks in a row
then it could display a message to the user.

Furthermore IP messages have checksums in them which should help
reduce issues with interference, further checksums could be added to
the application level messages.

Jason: I don't really have schematics but the readme file in the tar
file (http://chrisd.info/beagleRC/servosource.tar.gz) has a
description of the wiring. It is pretty simple, just 3 wires per
servo, and no other electrical components involved. Also hooking up
LEDs should be simple, just hook a resistor to the gpio, and then hook
the LED to the output of the resistor and ground and it should glow at
different levels depending on the pulse width. You also mentioned that
you haven't seen the host side code, but it is also in the
servosource.tar.gz, just look in the host directory.

Any other questions? I should be able to check back sometime soon. :smiley:

Thanks
    Chris D.

14

I'm happy with that. I'll be looking for some sort of feedback from each of the judges some time on Monday. I should be on IRC in the US morning time.

15

Hello,

Appologies in advance if I sound a bit negative. I do not mean to discourage.

The RT project looks interesting but it seems very ambitious. Would like to
see more details. Stats on number of bugs found and the types of bugs would
make more interesting to me.

I was not aware the project should be running already, in order to
enter the contest? If so, then please disregard mine.

I'm not sure if it's ambitious, at least it is a risky project
timewise; The real kernel work is already done by the -rt people and
previous releases have been tested in the community on ARM platforms,
no reason to see big problem except for yet hidden locking bugs in the
omap specific drivers. Maybe the kernel work is zero (!) in this
project, or very hard (tracking down proper use of locking can be
tempting.)

On another platform I only found and fixed one kernel bug so far:
http://lkml.org/lkml/2008/7/5/96

The project is mainly about creating a user land demonstration for
hard real-time, but I'm always eager to dive into the kernel code if I
can analyse where it breaks, and fix where I have the knowledge. The
aim would be 2.6.28, because that's where the -rt kernel is going
next. So it also depends on the omap kernel stuff being with 2.6.28.

Regards,

16

Hello,

Appologies in advance if I sound a bit negative. I do not mean to discourage.

The RT project looks interesting but it seems very ambitious. Would like to
see more details. Stats on number of bugs found and the types of bugs would
make more interesting to me.

I was not aware the project should be running already, in order to
enter the contest? If so, then please disregard mine.

I think it is not necessary for the project to be running in order to enter, but it will
weigh heavily in the selection of a winning project. :slight_smile:

I'm not sure if it's ambitious, at least it is a risky project
timewise; The real kernel work is already done by the -rt people and
previous releases have been tested in the community on ARM platforms,
no reason to see big problem except for yet hidden locking bugs in the
omap specific drivers. Maybe the kernel work is zero (!) in this
project, or very hard (tracking down proper use of locking can be
tempting.)

On another platform I only found and fixed one kernel bug so far:
http://lkml.org/lkml/2008/7/5/96

The project is mainly about creating a user land demonstration for
hard real-time, but I'm always eager to dive into the kernel code if I
can analyse where it breaks, and fix where I have the knowledge. The
aim would be 2.6.28, because that's where the -rt kernel is going
next. So it also depends on the omap kernel stuff being with 2.6.28.

Regards,
--
Leon

Thanks for the entry. I expect we will judge the existing entries in
upcoming contests, so keeping your entry up-to-date will be helpful.

17

Okay, fine.

Robert

18

I'm happy with that. I'll be looking for some sort of feedback from
each of the judges some time on Monday. I should be on IRC in the US
morning time.

Updated feedback -
Of all the entries these are the ones that, IMO, have enough progress,
info for this month:
QEMU (based on replies from the previous mail)
BeagleRC
Beagle Bot
Android

The other remaining one doesn't appear to have a lot of progress.

The Linux RT one is on the border. From the reply, it appears
it hasn't gone very far. (Context for this comment: I have worked
on a similar effort before and there are some classes of bugs
expected.). Look forward to seeing updates. Given that this is a
somewhat large project, I think the most reasonable way to evaluate
it is on the kinds of bugs fixed as that would reflect the testing
done on it and the overall progress.

From the 4 listed above:
I would rank them as -
1. BeagleRC
2. Beagle Bot
3. QEMU
4. Android

The Beagle bot and the BeagleRC projects are close. I would like to see
some more progress on the WebCam on the Beagle Bot. [See notes below.]
Both of these projects have a web page that could be taken as a demo
of the current state of things. I think this is what seperates them
from the others.

QEMU is nice and in the longer run might be great but it is a bit early
to tell. If it gets far enough along and the emulation is accurate enough,
it could be a nice test platform for some of the drivers (MUSB is the one
I am most interested in.)

The Beagle Android project as entered is not impressive because -
1. The is not much presented. Android itself is mature enough that there
are things to show. With a working keyboard, screen shots of things would
have been nice. Or at least a webpage text write up. I realize there is
limited time.

2. It does not distinguish itself from other "ports". I have done
work with the first preview of Android on another OMAP3 board and right now
it seems what is there is less then what was shown a many months ago. (Again,
this is from what is presented not what you may have.)

No offense intended with any of these comments.

Side notes not directly related to the contest -
It seems there are many people having problems with the gspca webcam driver.
Would there be an objection to or interest in me trying to gather these
reports to see if there is a pattern. My interest in this is simple; I have
tried 3 gspca cameras and they range from working to totally not enumerating.
If there is interest and no objections, I will send out a seperate mail.

19

I'm happy with that. I'll be looking for some sort of feedback from
each of the judges some time on Monday. I should be on IRC in the US
morning time.

Updated feedback -
Of all the entries these are the ones that, IMO, have enough progress,
info for this month:
QEMU (based on replies from the previous mail)
BeagleRC
Beagle Bot
Android

Since last week another project got added:

http://elinux.org/BeagleBoard/James

The other remaining one doesn't appear to have a lot of progress.

The Linux RT one is on the border. From the reply, it appears
it hasn't gone very far. (Context for this comment: I have worked
on a similar effort before and there are some classes of bugs
expected.). Look forward to seeing updates. Given that this is a
somewhat large project, I think the most reasonable way to evaluate
it is on the kinds of bugs fixed as that would reflect the testing
done on it and the overall progress.

From the 4 listed above:
I would rank them as -
1. BeagleRC
2. Beagle Bot
3. QEMU
4. Android

My ranking would be:

1) James
2) beaglebot
3) beaglerc

regards,

Koen

20

Hi Hunyue,

The musb gadget work (my entry) is almost complete, I had to do more
testing this night merging some clocking changes I need to do from
looking at the usb host patches, but the code is feature complete.

Diego