[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Brian Austin]

All,

I would like to start the process of adding the Cirrus Logic EP93XX ARM9
family to buildroot.

couple things about the 93xx.

1.  Maverick Crunch  FPU.  I have patches for GCC/uClibc to enable
Crunch FPU.

2. Linux Kernel.  We have a patch for several current kernel versions up
to 2.6.21.5.

I also have patches for DirectFB which I submitted last week and QT,
TSLIB, and other BSP software which have not been submitted.

I also think there is a section for bootloaders as well?

Qustion is,  where to start?

Right now we give out a modified version of buildroot for the prebuilt
toolchain and a buildroot system for building the kernel, u-boot,
redboot (ecos), and BSP software.  But I want it to go into ya'lls to
make things more consistent.  it's hard for me to do everything here.
We use DirectFB/GTK now for our graphics and I had to change alot to get
it to build and install correctly to pass SQA testing, so hopefully that
can be of use as well.

anyway comments and suggestions on where to start would be great.

Regards,
Brian Austin
Cirrus Logic Inc. 

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Ivan Kuten]

Brian Austin ?????:
> All,
> 
> I would like to start the process of adding the Cirrus Logic EP93XX ARM9
> family to buildroot.
> 
> couple things about the 93xx.
> 
> 1.  Maverick Crunch  FPU.  I have patches for GCC/uClibc to enable
> Crunch FPU.
> 
> 2. Linux Kernel.  We have a patch for several current kernel versions up
> to 2.6.21.5.
> 
> I also have patches for DirectFB which I submitted last week and QT,
> TSLIB, and other BSP software which have not been submitted.
> 
> I also think there is a section for bootloaders as well?
> 
> Qustion is,  where to start?
> 
> Right now we give out a modified version of buildroot for the prebuilt
> toolchain and a buildroot system for building the kernel, u-boot,
> redboot (ecos), and BSP software.  But I want it to go into ya'lls to
> make things more consistent.  it's hard for me to do everything here.
> We use DirectFB/GTK now for our graphics and I had to change alot to get
> it to build and install correctly to pass SQA testing, so hopefully that
> can be of use as well.
> 
> anyway comments and suggestions on where to start would be great.
> 
> Regards,
> Brian Austin
> Cirrus Logic Inc. 
> 
> 

Hi Brian,

That's great that Cirrus decided to merge its verion of buildroot with mainline.
I was thinking to start adding Cirrus stuff to buildroot by myself, because we use EP93xx
 but need packages present in mainline buildroot.

Now that's a good chance to join efforts so that Cirrus EP93xx integration into buildroot go quickly.

I'd suggest you to take a look into target/device dir
and create layout for target/device/Cirrus

And start posting your patches. I think patches for packages are not very Cirrus CPU specific.

Best regards,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Bernhard Fischer]

On Wed, Oct 03, 2007 at 02:42:24AM +0300, Ivan Kuten wrote:
>Brian Austin ?????:
>> All,
>> 
>> I would like to start the process of adding the Cirrus Logic EP93XX ARM9
>> family to buildroot.
>> 
>> couple things about the 93xx.
>> 
>> 1.  Maverick Crunch  FPU.  I have patches for GCC/uClibc to enable
>> Crunch FPU.
>> 
>> 2. Linux Kernel.  We have a patch for several current kernel versions up
>> to 2.6.21.5.
>> 
>> I also have patches for DirectFB which I submitted last week and QT,
>> TSLIB, and other BSP software which have not been submitted.
>> 
>> I also think there is a section for bootloaders as well?
>> 
>> Qustion is,  where to start?
>> 
>> Right now we give out a modified version of buildroot for the prebuilt
>> toolchain and a buildroot system for building the kernel, u-boot,
>> redboot (ecos), and BSP software.  But I want it to go into ya'lls to
>> make things more consistent.  it's hard for me to do everything here.
>> We use DirectFB/GTK now for our graphics and I had to change alot to get
>> it to build and install correctly to pass SQA testing, so hopefully that
>> can be of use as well.
>> 
>> anyway comments and suggestions on where to start would be great.
>> 
>> Regards,
>> Brian Austin
>> Cirrus Logic Inc. 
>> 
>> 
>
>Hi Brian,
>
>That's great that Cirrus decided to merge its verion of buildroot with mainline.
>I was thinking to start adding Cirrus stuff to buildroot by myself, because we use EP93xx
> but need packages present in mainline buildroot.
>
>Now that's a good chance to join efforts so that Cirrus EP93xx integration into buildroot go quickly.
>
>I'd suggest you to take a look into target/device dir
>and create layout for target/device/Cirrus

Depends a bit.. From the sounds, all but the configs should reside in
generic parts.
That said, I'm not too keen on building up a shadow of kernel.org, so
please
1) update your patches against current linus tree (or -mm, however you
see fit)
2) submit your patches upstream
>
>And start posting your patches. I think patches for packages are not very Cirrus CPU specific.

Posting separate, distinct and self-contained patches in a series is
certainly the way to go.
I'll do my best to help review and/or comment them.

cheers,
Bernhard

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Ivan Kuten]

> Depends a bit.. From the sounds, all but the configs should reside in
> generic parts.
> That said, I'm not too keen on building up a shadow of kernel.org, so
> please
> 1) update your patches against current linus tree (or -mm, however you
> see fit)
> 2) submit your patches upstream

Bernhard,

Let me not argee here. You are forcing "keep up-to-date" policy instead of
"stable release" policy.

Cirrus Patches may be not a part of buildroot but refer as URL on Cirrus web site.

In embedded world is it often that you have to stick to some old kernel version because
of dependency on 3rd components specific to that particular kernel version.

Take into account reasoning of usual linux developer - I do not want to update my kernel
patches for every (month,week) -mm released. I want to have a stable base - which remains stable
after half-of-year.

And submitting patches to mainstream takes long time. And we want Cirrus support now.

Best regards,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Ulf Samuelsson]

> 
>> Depends a bit.. From the sounds, all but the configs should reside in
>> generic parts.
>> That said, I'm not too keen on building up a shadow of kernel.org, so
>> please
>> 1) update your patches against current linus tree (or -mm, however you
>> see fit)
>> 2) submit your patches upstream
> 
> Bernhard,
> 
> Let me not argee here. You are forcing "keep up-to-date" policy instead of
> "stable release" policy.
> 
> Cirrus Patches may be not a part of buildroot but refer as URL on Cirrus web site.
> 
> In embedded world is it often that you have to stick to some old kernel version because
> of dependency on 3rd components specific to that particular kernel version.
> 
> Take into account reasoning of usual linux developer - I do not want to update my kernel
> patches for every (month,week) -mm released. I want to have a stable base - which remains stable
> after half-of-year.
> 
> And submitting patches to mainstream takes long time. And we want Cirrus support now.
> 
> Best regards,
> Ivan
> 

It is a significant problem, which is can be be resolved easily, 
as long as packages can be rebuilt without changing the makefile fragment.
If the Makefile fragment for a package is ifdef'ed, then you can supply your own
file which contains the desired  package version numbers.

ifeq ($(<PACKAGE>_VERSION),)
<PACKAGE>_VERSION:=X.Y.Z
endif

If the introduction of a new package, require that the Makefile fragment
changes, then the problem becomes worse.

Bernard wants you to freeze the buildroot source code for a specific customer.
Assume you have 50 customers, then you have 50 source trees to maintain.
If you want to add a single package for each customer, you have to edit 50 source trees.
Clearly not acceptable.



Best Regards
Ulf Samuelsson

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Brian Austin]

That sounds easy enough.

For the kernel I was planning on doing the same thing that is done with
the kernel headers used for the toolchain.

wouldnt that make sense?


On Thu, 2007-10-04 at 06:08 +0200, Ulf Samuelsson wrote:
> > 
> >> Depends a bit.. From the sounds, all but the configs should reside in
> >> generic parts.
> >> That said, I'm not too keen on building up a shadow of kernel.org, so
> >> please
> >> 1) update your patches against current linus tree (or -mm, however you
> >> see fit)
> >> 2) submit your patches upstream
> > 
> > Bernhard,
> > 
> > Let me not argee here. You are forcing "keep up-to-date" policy instead of
> > "stable release" policy.
> > 
> > Cirrus Patches may be not a part of buildroot but refer as URL on Cirrus web site.
> > 
> > In embedded world is it often that you have to stick to some old kernel version because
> > of dependency on 3rd components specific to that particular kernel version.
> > 
> > Take into account reasoning of usual linux developer - I do not want to update my kernel
> > patches for every (month,week) -mm released. I want to have a stable base - which remains stable
> > after half-of-year.
> > 
> > And submitting patches to mainstream takes long time. And we want Cirrus support now.
> > 
> > Best regards,
> > Ivan
> > 
> 
> It is a significant problem, which is can be be resolved easily, 
> as long as packages can be rebuilt without changing the makefile fragment.
> If the Makefile fragment for a package is ifdef'ed, then you can supply your own
> file which contains the desired  package version numbers.
> 
> ifeq ($(<PACKAGE>_VERSION),)
> <PACKAGE>_VERSION:=X.Y.Z
> endif
> 
> If the introduction of a new package, require that the Makefile fragment
> changes, then the problem becomes worse.
> 
> Bernard wants you to freeze the buildroot source code for a specific customer.
> Assume you have 50 customers, then you have 50 source trees to maintain.
> If you want to add a single package for each customer, you have to edit 50 source trees.
> Clearly not acceptable.
> 
> 
> 
> Best Regards
> Ulf Samuelsson
> 
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Bernhard Fischer]

On Thu, Oct 04, 2007 at 06:08:55AM +0200, Ulf Samuelsson wrote:
>> 
>>> Depends a bit.. From the sounds, all but the configs should reside in
>>> generic parts.
>>> That said, I'm not too keen on building up a shadow of kernel.org, so
>>> please
>>> 1) update your patches against current linus tree (or -mm, however you
>>> see fit)
>>> 2) submit your patches upstream
>> 
>> Bernhard,
>> 
>> Let me not argee here. You are forcing "keep up-to-date" policy instead of
>> "stable release" policy.

How so? I'm asking that you submit your patches to the respective
upstream maintainers for review and later inclusion.

>> Cirrus Patches may be not a part of buildroot but refer as URL on Cirrus web site.

This is an entirely different thing.

>> In embedded world is it often that you have to stick to some old kernel version because
>> of dependency on 3rd components specific to that particular kernel version.
>> 
>> Take into account reasoning of usual linux developer - I do not want to update my kernel
>> patches for every (month,week) -mm released. I want to have a stable base - which remains stable
>> after half-of-year.
>> 
>> And submitting patches to mainstream takes long time. And we want Cirrus support now.

Supporting some old version of packages with supplemental patches is
fine and one thing. Refusing even try to get your additions merged is
not a proper thing to do IMO.

It is extremely burdensome and impractical to have to patch every single
"new" upstream release (let alone time-consuming and thus probably
expensive if somebody pays the time you're spending on doing it).

>> Best regards,
>> Ivan

>Bernard wants you to freeze the buildroot source code for a specific customer.

Ulf, please stop to babble such crap. There is /dev/null for such
insults. Thank you.

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Bernhard Fischer]

On Sun, Oct 07, 2007 at 08:45:48PM +0300, Ivan Kuten wrote:

>Bernhard, I only wanted to notice that having Cirrus support in buildroot can be
>-before- then some of Cirrus patches go in mainline kernel. I'm aware about Cirrus patches
>to 2.6.20.4 and 2.6.17.14, and some of our customers still use 2.6.17.14 kernel version.

Sure. Please submit them for review and inclusion.

[Buildroot] Adding Cirrus EP93XX ARM to buildroot

[Ivan Kuten]

>>>
>>> And submitting patches to mainstream takes long time. And we want Cirrus support now.
> 
> Supporting some old version of packages with supplemental patches is
> fine and one thing. Refusing even try to get your additions merged is
> not a proper thing to do IMO.
> 
> It is extremely burdensome and impractical to have to patch every single
> "new" upstream release (let alone time-consuming and thus probably
> expensive if somebody pays the time you're spending on doing it).
> 

Bernhard, I only wanted to notice that having Cirrus support in buildroot can be
-before- then some of Cirrus patches go in mainline kernel. I'm aware about Cirrus patches
to 2.6.20.4 and 2.6.17.14, and some of our customers still use 2.6.17.14 kernel version.

BR,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------