[Buildroot] Report from the Buildroot Developers Meeting

[Buildroot] Report from the Buildroot Developers Meeting

[Thomas Petazzoni]

Hello,

As it had been announced on this list, a Buildroot Developers Meeting
took place earlier this week, on Monday and Tuesday in Brussels, right
after the FOSDEM conference. We'd like, again, to thank Google, who
kindly offered to host the meeting in the Brussels offices of the
company, providing excellent conditions for the meeting.

Seven persons participated to the meeting: Peter Korsgaard, Arnout
Vandecappelle, Samuel Martin, Thomas De Schampheleire, Yann E. Morin,
Dimitrios Siganos and myself;

During the meeting, a large number of topics have been discussed, and
notes were taken live, mainly by Arnout. Those notes are all available
on the wiki page of the event at:

  http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013#List_of_topics_to_discuss

Do not hesitate to comment those discussions as a reply to this e-mail.

In addition, I've done a quick summary of some of the most important
topics discussed, and included a nice picture of the participants in a
blog post on Emlinews:

  http://www.emlinews.net/2013/02/buildroot-developers-meeting-report/

While it has not been formally discussed during the meeting, it can be
assumed that the next Buildroot Developers Meeting will take place next
to the upcoming Embedded Linux Conference Europe (October 23-25 in
Edimburgh, UK).

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developers Meeting

[Stephan Hoffmann]

Am 09.02.2013 00:42, schrieb Thomas Petazzoni:
> Hello,
>
>
>   http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013#List_of_topics_to_discuss
>
> Do not hesitate to comment those discussions as a reply to this e-mail.
Hello all,

here my .02? to the discussions:

> What to do with systemd/udev/eudev: we try to use the udev from
> systemd without systemd. Exactly how we don't know yet... There's a
> risk that udev becomes unusable without systemd, but Leonard
> Poettering promised this would not happen. After a quick look, it
> turns out that you always end up building systemd, which requires
> dbus, even if you need only udev. So it makes the systemd source
> tarball a bit unpractical to build a system that uses udev only, and
> doesn't need systemd. Probably an indication that we should have a
> look at eudev? How would this interact with the systemd selection?
> What about incompatibilities between udev and eudev? 
What about using a different udev version with or without systemd? This
would allow using a recent systemd version while systems without it
could use the old udev or eudev, even as an option.

> Switching to ct-ng as the default toolchain backend has been in the
> plans for several years. But since it's not the default backend it
> isn't getting a lot of attention (example: for several months it was
> broken, libraries were not copied to the target, and it took a lot of
> time for somebody to notice). 
Regarding the toolchain I want to say that I really like buildroot's
ability to build a toolchain.

But I hate the fact that after every "make clean" the toolchain has to
be rebuilt completely from scratch which takes precious time.

Of course there is the possibility to change the output directory, build
the toolchain and then use it as an external toolchain, but this breaks
the nice integration between buildroot and it's toolchain and is not
really comfortable.

What about automating this process by splitting it up into building the
toolchain and afterwards copying it to output/{host/staging} like it is
done with external toolchains? "make clean" or maybe something new like
"make almostclean" would not clean the toolchain build directory, so
only the copy stage would be repeated. Another make target to clean
everything including the toolchain would be needed, of course.

> Handling of make xxx-menuconfig
>
>   * Conclusion: copy it back to the configured place, disallow
>     xxx-menuconfig unless something is configured. We always save full
>     config because defconfig is not always reliable.
>
As the one that brought up this topic I say that's a good compromise,
even though it means some inequality between handling buildroot's config
file and the others.

> Autobuilder status: Thomas will move the info to a database, and has
> some very basic webpages for accessing the database. He also dreams
> about running some tests in qemu - but we already have enough failures
> with the autobuilders as they are :-) 
I'd really like to have access to the results. For example it would be
interesting to see in which configuration a package fails and in which
not. I could think of cooking a script or program that extracts such
information on a package base.

Kind regards

Stephan
>
> In addition, I've done a quick summary of some of the most important
> topics discussed, and included a nice picture of the participants in a
> blog post on Emlinews:
>
>   http://www.emlinews.net/2013/02/buildroot-developers-meeting-report/
>
> While it has not been formally discussed during the meeting, it can be
> assumed that the next Buildroot Developers Meeting will take place next
> to the upcoming Embedded Linux Conference Europe (October 23-25 in
> Edimburgh, UK).
>
> Best regards,
>
> Thomas


-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

[Buildroot] Report from the Buildroot Developers Meeting

[Thomas Petazzoni]

Dear Stephan Hoffmann,

On Tue, 12 Feb 2013 11:30:00 +0100, Stephan Hoffmann wrote:

> > What to do with systemd/udev/eudev: we try to use the udev from
> > systemd without systemd. Exactly how we don't know yet... There's a
> > risk that udev becomes unusable without systemd, but Leonard
> > Poettering promised this would not happen. After a quick look, it
> > turns out that you always end up building systemd, which requires
> > dbus, even if you need only udev. So it makes the systemd source
> > tarball a bit unpractical to build a system that uses udev only, and
> > doesn't need systemd. Probably an indication that we should have a
> > look at eudev? How would this interact with the systemd selection?
> > What about incompatibilities between udev and eudev? 
> What about using a different udev version with or without systemd?
> This would allow using a recent systemd version while systems without
> it could use the old udev or eudev, even as an option.

Because on the long term we can't rely on an old version of udev that
is no longer maintained or updated. So keeping the old udev version is
not an option.

> > Switching to ct-ng as the default toolchain backend has been in the
> > plans for several years. But since it's not the default backend it
> > isn't getting a lot of attention (example: for several months it was
> > broken, libraries were not copied to the target, and it took a lot
> > of time for somebody to notice). 
> Regarding the toolchain I want to say that I really like buildroot's
> ability to build a toolchain.
> 
> But I hate the fact that after every "make clean" the toolchain has to
> be rebuilt completely from scratch which takes precious time.
> 
> Of course there is the possibility to change the output directory,
> build the toolchain and then use it as an external toolchain, but
> this breaks the nice integration between buildroot and it's toolchain
> and is not really comfortable.
> 
> What about automating this process by splitting it up into building
> the toolchain and afterwards copying it to output/{host/staging} like
> it is done with external toolchains? "make clean" or maybe something
> new like "make almostclean" would not clean the toolchain build
> directory, so only the copy stage would be repeated. Another make
> target to clean everything including the toolchain would be needed,
> of course.

Why don't you build your external toolchain once, put it in a tarball,
and then point Buildroot to it? You have to do this only once, and you
can even put your toolchain tarball on a server so that others can use
it without having to rebuild the toolchain.

> > Autobuilder status: Thomas will move the info to a database, and has
> > some very basic webpages for accessing the database. He also dreams
> > about running some tests in qemu - but we already have enough
> > failures with the autobuilders as they are :-) 
> I'd really like to have access to the results. For example it would be
> interesting to see in which configuration a package fails and in which
> not. I could think of cooking a script or program that extracts such
> information on a package base.

Not sure to understand what you want to do exactly, but the results
have since a long time been publicly available at
http://autobuild.buildroot.org.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developers Meeting

[Stephan Hoffmann]

Am 12.02.2013 11:36, schrieb Thomas Petazzoni:
> Dear Stephan Hoffmann,
>
> On Tue, 12 Feb 2013 11:30:00 +0100, Stephan Hoffmann wrote:
>

>>> Switching to ct-ng as the default toolchain backend has been in the
>>> plans for several years. But since it's not the default backend it
>>> isn't getting a lot of attention (example: for several months it was
>>> broken, libraries were not copied to the target, and it took a lot
>>> of time for somebody to notice). 
>> Regarding the toolchain I want to say that I really like buildroot's
>> ability to build a toolchain.
>>
>> But I hate the fact that after every "make clean" the toolchain has to
>> be rebuilt completely from scratch which takes precious time.
>>
>> Of course there is the possibility to change the output directory,
>> build the toolchain and then use it as an external toolchain, but
>> this breaks the nice integration between buildroot and it's toolchain
>> and is not really comfortable.
>>
>> What about automating this process by splitting it up into building
>> the toolchain and afterwards copying it to output/{host/staging} like
>> it is done with external toolchains? "make clean" or maybe something
>> new like "make almostclean" would not clean the toolchain build
>> directory, so only the copy stage would be repeated. Another make
>> target to clean everything including the toolchain would be needed,
>> of course.
> Why don't you build your external toolchain once, put it in a tarball,
> and then point Buildroot to it?
Because, as I wrote, I like the concept to have it integrated in
buildroot's configuration.
>  You have to do this only once, and you
> can even put your toolchain tarball on a server so that others can use
> it without having to rebuild the toolchain.
>
What's the advantage of your proposal against using ct-ng to build the
toolchain or use a prepared one from somewhere else?

Kind regards

Stephan

>
> Best regards,
>
> Thomas


-- 
reLinux     -    Stephan Hoffmann
Am Schmidtgrund 124    50765 K?ln
Tel. +49.221.95595-19    Fax: -64
www.reLinux.de     sho at reLinux.de

[Buildroot] Report from the Buildroot Developers Meeting

[Thomas Petazzoni]

Dear Stephan Hoffmann,

On Tue, 12 Feb 2013 12:49:15 +0100, Stephan Hoffmann wrote:

> > Why don't you build your external toolchain once, put it in a
> > tarball, and then point Buildroot to it?
> Because, as I wrote, I like the concept to have it integrated in
> buildroot's configuration.

It's integrated in your configuration: your Buildroot configuration
says "use toolchain from http://foobar.com/toolchain.tar.gz", and
that's it.

> >  You have to do this only once, and you
> > can even put your toolchain tarball on a server so that others can
> > use it without having to rebuild the toolchain.
>
> What's the advantage of your proposal against using ct-ng to build the
> toolchain or use a prepared one from somewhere else?

There's no advantage because my proposal is exactly what you state
here: prepare a toolchain first (could be with Buildroot, with ct-ng,
or some other pre-existing toolchain), and use it with Buildroot as an
external toolchain.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developers Meeting

[Stefan Fröberg]

>> What to do with systemd/udev/eudev: we try to use the udev from
>> systemd without systemd. Exactly how we don't know yet... There's a
>> risk that udev becomes unusable without systemd, but Leonard
>> Poettering promised this would not happen. After a quick look, it
>> turns out that you always end up building systemd, which requires
>> dbus, even if you need only udev. So it makes the systemd source
>> tarball a bit unpractical to build a system that uses udev only, and
>> doesn't need systemd. Probably an indication that we should have a
>> look at eudev? How would this interact with the systemd selection?
>> What about incompatibilities between udev and eudev? 
> What about using a different udev version with or without systemd? This
> would allow using a recent systemd version while systems without it
> could use the old udev or eudev, even as an option.

Here's what Linux from Scratch project does

http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html

They just rip the udev off from the latest systemd tarball
(systemd-197.tar.xz) and use that.


>> Switching to ct-ng as the default toolchain backend has been in the
>> plans for several years. But since it's not the default backend it
>> isn't getting a lot of attention (example: for several months it was
>> broken, libraries were not copied to the target, and it took a lot of
>> time for somebody to notice). 
> Regarding the toolchain I want to say that I really like buildroot's
> ability to build a toolchain.

Ditto. I like it too that buildroot has all in the box and that I don't
need to have any
separate cross-compiler toolchain installed.
And also the fact that I don't have to muck with any possible config
problems
of external cross-compiler.

Regards
Stefan

[Buildroot] Report from the Buildroot Developers Meeting

[Daniel Nyström]

On Sat, Feb 9, 2013 at 12:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>   http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013#List_of_topics_to_discuss
> Do not hesitate to comment those discussions as a reply to this e-mail.

> The problem of systemd and udev has been discussed. Buildroot is currently
> stuck with an old version of systemd and udev, because the project wants to
> be able to offer udev-based systems that don?t use systemd. Unfortunately,
> the modern version of systemd directly integrate udev, and it is not possible
> to build the latter without building the former, bringing D-Bus as a
> dependency. Investigating the eudev fork was discussing, but relying on a
> forked version of udev may be causing compatibility issues in the future.

According to the announcement of udev and systemd being merged, they
claimed udev would still be able to be build independently (although
through the systemd source tree of course). I requested some info
regarding the D-Bus dependency in #systemd and here is the dialog:

< speakman> Just heard about udev and systemd merging. And it seems
like udev can still be compiled individually although from the same
source tree as systemd. But how about it's DBus dependency - will
"udev" compile without D-Bus libraries?
< ssuominen> speakman: yes, but you have to call specific Makefile.am
targets individually... and set environment flags DBUS_CFLAGS=' ' and
DBUS_LIBS='
                   ' to get past the ./configure check
< ssuominen> speakman: gentoo is packaging udev like that, and ebuilds
are mostly bash, you could take look at the rather complex setup from
the ebuild

So, although it might be a bit complex, it seems like udev can be
built independently without dbus libraries.

Regarding Buildroot I assume dbus and systemd will merge into one
single package. Are there anything preventing "systemd" from being
"optional" and depend on D-Bus only when enabled?

Anything else I'm missing here?

Best regards
Daniel

[Buildroot] Report from the Buildroot Developers Meeting

[Thomas Petazzoni]

Dear Daniel Nystr?m,

On Tue, 12 Feb 2013 15:14:37 +0100, Daniel Nystr?m wrote:

> According to the announcement of udev and systemd being merged, they
> claimed udev would still be able to be build independently (although
> through the systemd source tree of course). I requested some info
> regarding the D-Bus dependency in #systemd and here is the dialog:
> 
> < speakman> Just heard about udev and systemd merging. And it seems
> like udev can still be compiled individually although from the same
> source tree as systemd. But how about it's DBus dependency - will
> "udev" compile without D-Bus libraries?
> < ssuominen> speakman: yes, but you have to call specific Makefile.am
> targets individually... and set environment flags DBUS_CFLAGS=' ' and
> DBUS_LIBS='
>                    ' to get past the ./configure check
> < ssuominen> speakman: gentoo is packaging udev like that, and ebuilds
> are mostly bash, you could take look at the rather complex setup from
> the ebuild

Interesting, thanks for asking about this topic.

Note that there was an effort last year to make this easier:
http://comments.gmane.org/gmane.linux.hotplug.devel/17478. But it
doesn't seem to have been merged, and the systemd maintainers don't
think building D-Bus is a problem:
http://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html.

> Regarding Buildroot I assume dbus and systemd will merge into one
> single package. Are there anything preventing "systemd" from being
> "optional" and depend on D-Bus only when enabled?

Why would systemd and dbus would merge into one single package? Are you
sure you didn't confuse with "systemd and udev would merge into one
single package" ?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Report from the Buildroot Developers Meeting

[Daniel Nyström]

On Tue, Feb 12, 2013 at 3:18 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Daniel Nystr?m,
> On Tue, 12 Feb 2013 15:14:37 +0100, Daniel Nystr?m wrote:
>> According to the announcement of udev and systemd being merged, they
>> claimed udev would still be able to be build independently (although
>> through the systemd source tree of course). I requested some info
>> regarding the D-Bus dependency in #systemd and here is the dialog:
>>
>> < speakman> Just heard about udev and systemd merging. And it seems
>> like udev can still be compiled individually although from the same
>> source tree as systemd. But how about it's DBus dependency - will
>> "udev" compile without D-Bus libraries?
>> < ssuominen> speakman: yes, but you have to call specific Makefile.am
>> targets individually... and set environment flags DBUS_CFLAGS=' ' and
>> DBUS_LIBS='
>>                    ' to get past the ./configure check
>> < ssuominen> speakman: gentoo is packaging udev like that, and ebuilds
>> are mostly bash, you could take look at the rather complex setup from
>> the ebuild
>
> Interesting, thanks for asking about this topic.
>
> Note that there was an effort last year to make this easier:
> http://comments.gmane.org/gmane.linux.hotplug.devel/17478. But it
> doesn't seem to have been merged, and the systemd maintainers don't
> think building D-Bus is a problem:
> http://lists.freedesktop.org/archives/systemd-devel/2012-June/005516.html.

That's one sad attitude by the developers. Looks like we're on our own here.

>> Regarding Buildroot I assume dbus and systemd will merge into one
>> single package. Are there anything preventing "systemd" from being
>> "optional" and depend on D-Bus only when enabled?
>
> Why would systemd and dbus would merge into one single package? Are you
> sure you didn't confuse with "systemd and udev would merge into one
> single package" ?

That's my typo, sorry.

[Buildroot] Report from the Buildroot Developers Meeting

[Yann E. MORIN]

Thomas, All,

On Saturday 09 February 2013 Thomas Petazzoni wrote:
> During the meeting, a large number of topics have been discussed, and
> notes were taken live, mainly by Arnout. Those notes are all available
> on the wiki page of the event at:
>   http://elinux.org/Buildroot:DeveloperDaysFOSDEM2013#List_of_topics_to_discuss

Amongst those topics was the possibility for Buildroot to submit a
proposal for the next Googl Summer of Code (GSoC). The schedule for
GSoC`13 has now been published:
    https://www.google-melange.com/gsoc/events/google/gsoc2013

In short:
  - mentoring applications must be sent from 2013-03-18 19:00Z, and
    no later than 2013-03-29 19:00Z.
  - list of accepted mentoring organisations published on 2013-04-08 19:00Z
  - students start working 2013-06-17, until 2013-09-23 19:00Z
  - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)

Now, we're left to imagining what we'll be submitting. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Report from the Buildroot Developers Meeting

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 13 Feb 2013 19:55:35 +0100, Yann E. MORIN wrote:

> Amongst those topics was the possibility for Buildroot to submit a
> proposal for the next Googl Summer of Code (GSoC). The schedule for
> GSoC`13 has now been published:
>     https://www.google-melange.com/gsoc/events/google/gsoc2013
> 
> In short:
>   - mentoring applications must be sent from 2013-03-18 19:00Z, and
>     no later than 2013-03-29 19:00Z.
>   - list of accepted mentoring organisations published on 2013-04-08 19:00Z
>   - students start working 2013-06-17, until 2013-09-23 19:00Z
>   - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)
> 
> Now, we're left to imagining what we'll be submitting. ;-)

Yes, I've seen that. The Buildroot project also needs to be vouched by
another organization or a Googler, to support our proposals. And I'm
proud to announce that I've already found a Googler who is ready to
support our proposals.

I'll work on writing one or two proposals.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Google Summer of Code 2013

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Wed, 13 Feb 2013 19:55:35 +0100, Yann E. MORIN wrote:

> Amongst those topics was the possibility for Buildroot to submit a
> proposal for the next Googl Summer of Code (GSoC). The schedule for
> GSoC`13 has now been published:
>     https://www.google-melange.com/gsoc/events/google/gsoc2013
> 
> In short:
>   - mentoring applications must be sent from 2013-03-18 19:00Z, and
>     no later than 2013-03-29 19:00Z.
>   - list of accepted mentoring organisations published on 2013-04-08 19:00Z
>   - students start working 2013-06-17, until 2013-09-23 19:00Z
>   - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)
> 
> Now, we're left to imagining what we'll be submitting. ;-)

I've written down three ideas:
http://elinux.org/Buildroot:GSoC2013Ideas.

Comments on those ideas are welcome, as well as additional ideas.

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Google Summer of Code 2013

[Thomas Petazzoni]

On Thu, 14 Feb 2013 15:25:47 +0100, Thomas Petazzoni wrote:

> > In short:
> >   - mentoring applications must be sent from 2013-03-18 19:00Z, and
> >     no later than 2013-03-29 19:00Z.
> >   - list of accepted mentoring organisations published on 2013-04-08 19:00Z
> >   - students start working 2013-06-17, until 2013-09-23 19:00Z
> >   - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)
> > 
> > Now, we're left to imagining what we'll be submitting. ;-)
> 
> I've written down three ideas:
> http://elinux.org/Buildroot:GSoC2013Ideas.
> 
> Comments on those ideas are welcome, as well as additional ideas.

Any opinions about this?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Google Summer of Code 2013

[Thomas De Schampheleire]

Hi Thomas,

On Sun, Mar 3, 2013 at 2:43 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> On Thu, 14 Feb 2013 15:25:47 +0100, Thomas Petazzoni wrote:
>
>> > In short:
>> >   - mentoring applications must be sent from 2013-03-18 19:00Z, and
>> >     no later than 2013-03-29 19:00Z.
>> >   - list of accepted mentoring organisations published on 2013-04-08 19:00Z
>> >   - students start working 2013-06-17, until 2013-09-23 19:00Z
>> >   - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)
>> >
>> > Now, we're left to imagining what we'll be submitting. ;-)
>>
>> I've written down three ideas:
>> http://elinux.org/Buildroot:GSoC2013Ideas.
>>
>> Comments on those ideas are welcome, as well as additional ideas.
>
> Any opinions about this?

Thanks for your efforts in writing this down!

A few small remarks:
- For the ARM SoC multimedia support, one of the steps written is:
"Get some packages accepted upstream in the official Buildroot Git
repository, by going through the traditional patch submission/review
process."
In my opinion, the goal is to get *all* packages accepted upstream.
With a partial integration, someone else will have to pick up the
remaining patches and prepare them for inclusion.

- For the Blackfin integration project, I think that prior
experience/knowledge with/about Blackfin and/or other no-MMU platforms
would also be a plus.

- Finally, for the testing infrastructure: in addition to the qemu
testing, it would also be nice if we had automatic real target testing
on some boards, for example with Beaglebone/Beagleboard/Pandaboard.
This would require some of these boards to be permanently hooked up to
a host machine, and a set of tests to execute on the device. Being
able to remotely reset the board even without a booting system would
also be nice, to prevent needing to much manual rescuing. Obviously,
this is more involved than with qemu, and we'd need a place where
these setups are hosted (somewhere at Peter's place or in Free
Electron's offices?) It may also be too much for this GSoC, but I
thought I'd mention it anyway.

Best regards,
Thomas

[Buildroot] Google Summer of Code 2013

[Stephan Hoffmann]

Am 03.03.2013 14:43, schrieb Thomas Petazzoni:
> On Thu, 14 Feb 2013 15:25:47 +0100, Thomas Petazzoni wrote:
>
>>> In short:
>>>   - mentoring applications must be sent from 2013-03-18 19:00Z, and
>>>     no later than 2013-03-29 19:00Z.
>>>   - list of accepted mentoring organisations published on 2013-04-08 19:00Z
>>>   - students start working 2013-06-17, until 2013-09-23 19:00Z
>>>   - mentor submit is on 2013-10-19 and 2013-10-20 (at Google HQs?)
>>>
>>> Now, we're left to imagining what we'll be submitting. ;-)
>> I've written down three ideas:
>> http://elinux.org/Buildroot:GSoC2013Ideas.
>>
>> Comments on those ideas are welcome, as well as additional ideas.
> Any opinions about this?
Hello Thomas,

I think all the suggestions are good, but the ARM SoC multimedia
libraries are most important. These chips seem to become very popular,
especially since there are low-cost platforms available as Beaglebone,
Pengwyn, Wandboard or Raspberry Pi. As I have seen at the Embedded World
in Nuremberg last week there are lots of industrial grade boards and
modules especially with iMX5x, iMX6 and AM335x available or introduced.
I expect that these systems will get a significant market share soon. So
it might be really important to have good support for them in buildroot.

There are gazillions of such SoC available, but I think that Freescale
and Texas are the most wide spread. Of course we cannot leave out RPi,
although  I do not think that it has a significance in the industrial
sector.

Maybe we should think about splitting this up into different projects,
since the three platforms might be to much for one student.

Regarding the autotests I'd really like to see some automatically tested
well-defined configurations, also regarding the SoC multimedia
libraries. These could also be a convenient start point for new users.

Kind regards

Stephan
>
> Thanks,
>
> Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130303/d9da4a46/attachment.html>

[Buildroot] Google Summer of Code 2013

[Thomas Petazzoni]

Dear Stephan Hoffmann,

On Sun, 03 Mar 2013 18:51:29 +0100, Stephan Hoffmann wrote:

> I think all the suggestions are good, but the ARM SoC multimedia
> libraries are most important. These chips seem to become very popular,
> especially since there are low-cost platforms available as Beaglebone,
> Pengwyn, Wandboard or Raspberry Pi. As I have seen at the Embedded World
> in Nuremberg last week there are lots of industrial grade boards and
> modules especially with iMX5x, iMX6 and AM335x available or introduced.
> I expect that these systems will get a significant market share soon. So
> it might be really important to have good support for them in buildroot.
> 
> There are gazillions of such SoC available, but I think that Freescale
> and Texas are the most wide spread. Of course we cannot leave out RPi,
> although  I do not think that it has a significance in the industrial
> sector.
> 
> Maybe we should think about splitting this up into different projects,
> since the three platforms might be to much for one student.

I think we should maybe get started with only one GSoC project, since
we don't have much experience in mentoring a student.

The only issue with the topic related to multimedia packages for ARM
SoCs is that it requires some hardware, and I'm not sure where to get
the funding for that. Google says they pay $500 to the mentoring
organization, but I think this gets paid at the end of the GSoC, and
anyway we don't have any legal organization to receive this money.

Another solution is to get a little bit of sponsoring: getting one
BeagleBone and one i.MX6 based board sponsored shouldn't be too hard.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Google Summer of Code 2013

[Arnout Vandecappelle]

On 03/03/13 19:26, Thomas Petazzoni wrote:
> The only issue with the topic related to multimedia packages for ARM
> SoCs is that it requires some hardware, and I'm not sure where to get
> the funding for that. Google says they pay $500 to the mentoring
> organization, but I think this gets paid at the end of the GSoC, and
> anyway we don't have any legal organization to receive this money.
>
> Another solution is to get a little bit of sponsoring: getting one
> BeagleBone and one i.MX6 based board sponsored shouldn't be too hard.

  Don't quote me on this, but I might be able to get my hands on a 
Gumstix Overo, with display and everything. Second-hand, of course.

  Regards,
  Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Google Summer of Code 2013

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Tue, 05 Mar 2013 07:25:25 +0100, Arnout Vandecappelle wrote:

> > Another solution is to get a little bit of sponsoring: getting one
> > BeagleBone and one i.MX6 based board sponsored shouldn't be too hard.
> 
>   Don't quote me on this, but I might be able to get my hands on a 
> Gumstix Overo, with display and everything. Second-hand, of course.

Ok. Then I'll try to work on the administrative details to submit this
proposal. I think it's safe to say that participant to the GSoC this
year with only one proposal of topic is more reasonable. Having to
support multiple students could be difficult.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Google Summer of Code 2013

[Jérôme Pouiller]

On Tuesday 05 March 2013 07:25:25 Arnout Vandecappelle wrote:
> On 03/03/13 19:26, Thomas Petazzoni wrote:
> > The only issue with the topic related to multimedia packages for ARM
> > SoCs is that it requires some hardware, and I'm not sure where to get
> > the funding for that. Google says they pay $500 to the mentoring
> > organization, but I think this gets paid at the end of the GSoC, and
> > anyway we don't have any legal organization to receive this money.
> > 
> > Another solution is to get a little bit of sponsoring: getting one
> > BeagleBone and one i.MX6 based board sponsored shouldn't be too hard.
> 
>   Don't quote me on this, but I might be able to get my hands on a
> Gumstix Overo, with display and everything. Second-hand, of course.
If needed, I may also lend a computer on module with an i.MX6 
(http://www.congatec.com/products/qseven/dView/conga-qmx6.html) and the 
associated development board with an LCD display, audio output, 
etc...

-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr