BeagleBoard software design competition #1 to give away a Rev C prototype the first week of January
Jason Kridner
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
Hunyue Yau
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. ;)
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.
Hunyue Yau
http://www.hy-research.com/
Hunyue Yau
Jason Kridner
On Dec 18, 2008, at 11:27 PM, Hunyue Yau wrote:
> 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.
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. ;)
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.
on the wishlist.
Jason Kridner
On Dec 18, 2008, at 11:27 PM, Hunyue Yau wrote:
> 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.
host machine OS and be bootable. Care would need to be taken to
ensure they fit onto all 1GB SD cards.
>
>
> 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. ;)
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?
>
>
> 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.
on the wishlist.
>
>
Hunyue Yau
> On Dec 18, 2008, at 11:27 PM, Hunyue Yau wrote:
>
> > 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. ;)
>
> 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.
....snip....
Hunyue Yau
>
> > 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. ;)
>
> 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.
....snip....
Måns Rullgård
> 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.
--
Måns Rullgård
ma...@mansr.com
Jason Kridner
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
Jason Kridner
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. :)
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
Jason Kridner
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?
Hunyue Yau
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.
>
> >
> > [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
> >
>
yajin
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.
---------------
yajin
http://vm-kernel.org/blog
Jason Kridner
Any thoughts on how/when to conclude this round? Then, perhaps we can
have a project-of-the-month in the future?
Regards,
Jason
On Dec 30 2008, 10:58 pm, yajin <yajinz...@vm-kernel.org> wrote:
> 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.
>
> ---------------
> On 12月31日, 上午10时18分, Hunyue Yau <ybea...@rehut.com> wrote:
>
> > > On Dec 30, 5:58 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> > > > 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. :)
>
> > > > 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 designcontest,
> > > > including the fact that most of the great BeagleBoard developers might
> > > > never be recognized by winning it.
>
> > > > project entry[2]. Even if you don't win thecontestthis time or the
> > > > 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
Koen Kooi
Op 2 jan 2009, om 18:42 heeft Jason Kridner het volgende geschreven:
>
> 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
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Beagle Board" group.
> To post to this group, send email to discu...@beagleboard.org.
> To unsubscribe from this group, send email to beagleboard...@beagleboard.org
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
jeanluis
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. :D
Thanks
Chris D.
On Dec 30 2008, 9:18 pm, Hunyue Yau <ybea...@rehut.com> wrote:
> > On Dec 30, 5:58 pm, Jason Kridner <jkrid...@beagleboard.org> wrote:
> > > 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.
>
Jason Kridner
>
> Op 2 jan 2009, om 18:42 heeft Jason Kridner het volgende geschreven:
>
>>
>> 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
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.
Leon Woestenberg
On Wed, Dec 31, 2008 at 3:18 AM, Hunyue Yau <ybe...@rehut.com> wrote:
> 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,
--
Leon
Jason Kridner
On Jan 3, 2009, at 6:58 PM, Leon Woestenberg wrote:
>
> Hello,
>
> On Wed, Dec 31, 2008 at 3:18 AM, Hunyue Yau <ybe...@rehut.com> wrote:
>> 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. :)
>
>
> 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.
Robert Kuhn
>> 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?
> 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.
Okay, fine.
Robert
Hunyue Yau
> 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.
Koen Kooi
Op 5 jan 2009, om 18:05 heeft Hunyue Yau het volgende geschreven:
>
>> 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
Diego Dompe
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
Hunyue Yau
> 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.
Minor clarification. I did see the readme. By webpage text write up, I
am referring to something with more content.
>
> 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.
--
Hunyue Yau
http://www.hy-research.com/
Steve Sakoman
>
> Op 5 jan 2009, om 18:05 heeft Hunyue Yau het volgende geschreven:
>> 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
My list is:
1) beaglebot
2) beaglerc
3) qemu
Beaglebot takes first for the best overall combination of "wow
factor", quality/quantity of submission documentation, and actual
development progress.
Steve
Robert Kuhn
> My ranking would be:
>
> 1) James
> 2) beaglebot
> 3) beaglerc
My would be
1. beaglebot
2. qemu3
3. USB Support in U-boot
about 3. i am quite unsure. Lets see.
Bye - Robert
Måns Rullgård
1. BeagleBot
This has plenty of "wow", and it is well-documented. Videos show
the project is progressing well.
2. USB Support in U-boot
This could be useful when a serial port is not available, or simply
to reduce the amount of cables.
3. qemu-omap3
A good emulator can be very useful for low-level driver debugging,
so qemu support for omap3 would be welcome. The project seems to
be making progress even though a lot of work remains.
--
Måns Rullgård
ma...@mansr.com
Jason Kridner
On Jan 5, 2009, at 4:32 PM, Måns Rullgård wrote:
>
> Jason Kridner <jkri...@beagleboard.org> writes:
>
>> On Jan 2, 2009, at 11:47 AM, Koen Kooi wrote:
>>>
>>> Op 2 jan 2009, om 18:42 heeft Jason Kridner het volgende geschreven:
>>>
>>>>
>>>> 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
>>
>> 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.
My feedback:
* qemu-omap3: Lots of interesting progress. Not complete, but already
useful.
Entry is complete. (1)
* openGPS: Not ready yet. Interesting project. Might be good entry
next month.
* BeagleConf: Not ready yet. Interesting project. Might be good
entry next month.
* BealgeRC: Needs a project entry. Somewhat simple compared to
BeagleBot,
but I still like this entry a lot as it is easier to reproduce.
* LinuxRT: Not ready yet. Interesting project. Might be good entry
next month.
* USB support in U-boot: Heard this is close, but haven't seen it.
Needs to be
updated quickly for consideration this month. Otherwise will be
considered
next month. (4)
* James: Demo page was interesting, but project still seems to be in a
very
early phase and not packaged up in a way consumable easy for Beagle
users
yet. I think it shows a lot of promise and could be a good entry
next month.
* BeagleBot: I like this one a lot. It is difficult to reproduce, but
the videos and
documentation are very good. (2)
* Beagledroid: May not be the best Android out there, but I believe
this is a
very strong entry. (3)
I believe Dirk is the only one to not have given some feedback yet on
the
entries. Hopefully the contestants have seen this feedback such that
they
can improve their entry in a way they see fit and to notify us all of
those
changes here on this list.
How long do we need to give for final project updates? Thursday night,
Friday morning, midnight UTC?
How long do we need to give for voting? Sunday night, Monday morning,
midnight UTC?
Then I can get an address and ship a board on Monday?
Robert Kuhn
> How long do we need to give for final project updates? Thursday night,
> Friday morning, midnight UTC?
Friday afternoon. So all developers have a free weekend.
> How long do we need to give for voting? Sunday night, Monday morning,
> midnight UTC?
Monday morning so all judges can use they free weekend ;-)
> Then I can get an address and ship a board on Monday?
Sounds good.
Robert
Antti Seppanen
Mon, 5 Jan 2009, Hunyue Yau wrote:
> 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.
Definitely no objections from me as I'm very eager to get webcam working.
I just tried with 2.6.28-r1 kernel from OE with no success. Three cameras,
three failures. All of them enumerate perfectly but VIDIOCSYNC v4l1 ioctl
won't work with any of them. v4l1 to v4l2 transition layer is enabled at my
kernel config. I have not had any success with v4l2 applications, either.
Sometimes playing with camera also seems to kill my USB WLAN stixk (zd1211)
functionality resulting in usb i/o errors to the console.
> Hunyue Yau
> http://www.hy-research.com/
--
Antti Seppänen | PGP public key:
antti (á) hervanta.com | http://www.hervanta.com/~antti
OH3HMI
GSM +358-40-7540919
Frans Meulenbroeks
> * James: Demo page was interesting, but project still seems to be in a
> very
> early phase and not packaged up in a way consumable easy for Beagle
> users
> yet. I think it shows a lot of promise and could be a good entry
> next month.
Perhaps some things need clarification.
The PVR part of this is a set of programs that I wrote a while ago and
that runs on a Linksys NSLU2 (IXP420, ARMv5TE CPU).
For this contest I've revived the project (it got on the backburner
after a disk crash).
The UI that you see on http://195.241.226.180:13579/ is actually
delivered by the NSLU2 (that's why the address is so odd) and the
whole system as described on http://www.dse.nl/~meulenbr/pvr/pvr.html
works and can actually record video using the Hauppauge wintv pvr usb2
card (which connects over usb to the NSLU2).
For the demo, I have pruned the system in a few areas:
- There is functionality present to rip audio from a CD (including
title retrieval from CDDB) (a small relic of that still can be seen in
the Status screen)
- There is functionality to download pictures from a a digital camera
using PTP (this is done automatically when the camera is connected)
- There is functionality present to playback audio (using madplay);
The UI for that part is disabled, as I thought it would only confuse
people.
- It is possible to display video on the web page from a connected
webcam. This is disabled because the NSLU2 is in my living room, and I
do not want to expose my living room to the whole world.
Recordings are served by the NSLU2 to external UPnP renderers using
TwonkyVision (not open source so probably I'll replace it eventually
by ushare or coherence or so). Twonky is triggered to update its
content directory after a recording is made.
Also I did not get to updating the program guide data. Time was the
blocking factor here. I'll see if I can fix that before friday (but my
time next few days is very limited)
As I wrote before this whole system is working, and it is definitely
not in an early phase.
I have no idea how I can prove this, but you do not have to take my
word for it. Koen can testify this as he has seen it working.
And indeed, I agree that the program is not packaged up in a way which
is consumable for a Beagle user. There is a good reason for this: I do
not have a beagle board. I'll be the first one to order a rev C board
when they become available, but until then there seems little I can do
to make it more appealing to the Beagle community. Sorry about that
(and I know I can order a rev B board now, but the Mrs. would
definitely disagree that buying both a B and a C board is a good plan,
and the additional benefits of rev C make buying a B board now less
appealing to me).
Actually that was the main rationale to enter to contest: to give the
beagle version a 3 month headstart.
I hope this clarifies things (and if there are further questions do
not hesitate to contact me).
Frans.
PS: I'm not sure if all the judges indeed have seen the demo on
http://195.241.226.180:13579/ . If not please have a look and share
your comments. Be sure to read the demonstrator usage notes on
http://www.dse.nl/~meulenbr/pvr/pvr.html to learn about the UI (hint:
use arrow keys and on the EPG screen F1 and F3).
Dirk Behme
And now my my €.02
1a) QEMU
1b) BeagleBot
3) LinuxRT
4) U-Boot USB
QEMU and Bot are both at #1, but QEMU would be easier to demonstrate.
Dirk
Btw.: Anybody likes to add OpenOCD support? I added it as example but
had to remove it as I can't do it myself. I would rank it at #1, so if
you like to win, add it ;)
Dirk Behme
Agree.
Dirk
Frans Meulenbroeks
I have somewhat updated my submission.
The following changes have been made.
I've fetched the latest EPG data (using xmltv). This part used to have
some issues, that is why the previous version had old EPG data.
These are no fixed and now the system has actual EPG data for 139
channels. For the technically interested: I used the tv_grab_nl_upc
grabber.
Not all channels have logo's and some logo's look better than others.
I hope you will see through that.
I've also updated the project page (http://www.elinux.org/BeagleBoard/
James) to make more explicit what already runs and what not.
If you encounter a problem with the demo, please let me know (and
indicate in the subject something like BEAGLE as otherwise your
message might remain unnoticed in the LKML emails).
Also I would greatly appreciate it if you would let me know what you
find missing in my submission and how it should be improved to score
better next time. A lot of the system has to do with autonomous and
automatic functionality (e.g. auto importing pictures from a digital
camera) and is not easy to catch in a demo.
And finally: yes I know that a working demo with a beagle image would
be a big plus. However as explained before I have no beagle yet. Then
again I think I have a fairly solid proof of concept on NSLU2.
Good luck with the difficult task on judging all entries!
Frans.