[Buildroot] svn commit: trunk/buildroot/target/device/Atmel: atngw100 atngw100-base atngw100-expanded etc...

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel: atngw100 atngw100-base atngw100-expanded etc...

[ulf at uclibc.org]

Author: ulf
Date: 2008-05-05 18:38:09 -0700 (Mon, 05 May 2008)
New Revision: 21936

Log:
Update BR2_ATMEL_MIRROR in defconfigs

Added:
   trunk/buildroot/target/device/Atmel/atstk100x/atstk100x_defconfig

Removed:
   trunk/buildroot/target/device/Atmel/atstk100x/atstk1002_defconfig

Modified:
   trunk/buildroot/target/device/Atmel/atngw100-base/atngw100-base_defconfig
   trunk/buildroot/target/device/Atmel/atngw100-expanded/atngw100_expanded_defconfig
   trunk/buildroot/target/device/Atmel/atngw100/atngw100_defconfig
   trunk/buildroot/target/device/Atmel/atstk100x/atstk1002-no-mplayer_defconfig


Changeset:

Sorry, the patch is too large to include (1940 lines).
Please use ViewCVS to see it!

http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=21936

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel: atngw100 atngw100-base atngw100-expanded etc...

[John Voltz]

The ftp site seems to be out-of-date. The latest avr32 patches for gcc are
for version 4.2.2 with atmel patch 1.0.8. I'm not sure about the others
though. Also, they don't seem to be patched with the other uClibc patches as
well, and there is no facility in buildroot to patch the pre-patched files
either, as gcc 4.2.2 doesn't even have a toolchain directory. I've got
pre-patched sources here: ftp://64.31.81.93 that includes avr32-atmel.1.0.8
and all of the other uClibc patches as well. If you want to move them to the
at91 site that would be great. A couple of us AVR32 users have been
discussing the patch.avr32 scheme, is this out of the question?

Regards,
John Voltz


On Mon, May 5, 2008 at 9:38 PM, <ulf@uclibc.org> wrote:

> Author: ulf
> Date: 2008-05-05 18:38:09 -0700 (Mon, 05 May 2008)
> New Revision: 21936
>
> Log:
> Update BR2_ATMEL_MIRROR in defconfigs
>
> Added:
>   trunk/buildroot/target/device/Atmel/atstk100x/atstk100x_defconfig
>
> Removed:
>   trunk/buildroot/target/device/Atmel/atstk100x/atstk1002_defconfig
>
> Modified:
>
> trunk/buildroot/target/device/Atmel/atngw100-base/atngw100-base_defconfig
>
> trunk/buildroot/target/device/Atmel/atngw100-expanded/atngw100_expanded_defconfig
>   trunk/buildroot/target/device/Atmel/atngw100/atngw100_defconfig
>
> trunk/buildroot/target/device/Atmel/atstk100x/atstk1002-no-mplayer_defconfig
>
>
> Changeset:
>
> Sorry, the patch is too large to include (1940 lines).
> Please use ViewCVS to see it!
>
> http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=21936
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080505/c3782ed6/attachment-0001.htm 

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel:atngw100 atngw100-base atngw100-expanded etc...

[Ulf Samuelsson]

> The ftp site seems to be out-of-date. The latest avr32 patches for gcc are
> for version 4.2.2 with atmel patch 1.0.8. I'm not sure about the others
> though. Also, they don't seem to be patched with the other uClibc patches as
> well, and there is no facility in buildroot to patch the pre-patched files
> either, as gcc 4.2.2 doesn't even have a toolchain directory. I've got
> pre-patched sources here: ftp://64.31.81.93 that includes avr32-atmel.1.0.8
> and all of the other uClibc patches as well. If you want to move them to the
> at91 site that would be great. 

I will move this later this week.

> A couple of us AVR32 users have been
> discussing the patch.avr32 scheme, is this out of the question?

What is the benefit?
You can add patches to the AVR32 prepatched toolchain at "target/device/Atmel/toolchain"
Just need to add the correct directories.

The drawback of having patches inside the svn is that everyone not
using AVR32 will have to suffer the additional download.

> Regards,
> John Voltz



Best Regards
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel:atngw100 atngw100-base atngw100-expanded etc...

[Thiago A. Corrêa]

>
>  > A couple of us AVR32 users have been
>  > discussing the patch.avr32 scheme, is this out of the question?
>
>  What is the benefit?
>  You can add patches to the AVR32 prepatched toolchain at "target/device/Atmel/toolchain"
>  Just need to add the correct directories.
>
>  The drawback of having patches inside the svn is that everyone not
>  using AVR32 will have to suffer the additional download.

Anyone not using avahi suffers additional download for that package,
as well as java, or MIPS, or x86. Do you see where I'm getting?

The benefit are several:

- More eye balls: the underlying building is used and improved by many
different platforms. Improvements in one affects all. A breakage here
will be detected and fixed more rapidly.

- Freedom of access: anyone with commit access to SVN can fix or
update the whole system, there is no dependency on a single person.

- Less disk space consumed and bandwidth saved: Anyone building for
more than one platform doesn't require additional 50Mb per toolchain.
That's for all developers, everyone here has at least once built for a
different $(ARCH) than they usually do.

- It worked: the external toolchain doesnt.

- Gives visibility to patches: If a patch breaks an $(ARCH) all you
have to do is rename it, but you gain the knowleadge that the issue
exists, and the patch maintainer can be notified. This makes it easier
for patches to be accepted upstream later on.

- We could get rid of Atmel Specifics: In buildroot we have 2 flavors
of external toolchain: generic and Atmel. Kill Atmel.

Seriously, building an image takes several gigabytes, my dl dir has
1Gb of downloaded packages alone, when extracted they expand a lot,
when compiled, another 2 fold, how significant is a few patches?

Regards,
    Thiago A. Correa

[Buildroot] svn commit:trunk/buildroot/target/device/Atmel:atngw100 atngw100-baseatngw100-expanded etc...

[Ulf Samuelsson]

> >
>>  > A couple of us AVR32 users have been
>>  > discussing the patch.avr32 scheme, is this out of the question?
>>
>>  What is the benefit?
>>  You can add patches to the AVR32 prepatched toolchain at "target/device/Atmel/toolchain"
>>  Just need to add the correct directories.
>>
>>  The drawback of having patches inside the svn is that everyone not
>>  using AVR32 will have to suffer the additional download.
> 
> Anyone not using avahi suffers additional download for that package,
> as well as java, or MIPS, or x86. Do you see where I'm getting?
> 

No, you only download what you want to build.
I think you are confusing the contents of the defconfigs with 
the configuration used in a real product.
The defconfigs are examples, or starting points, and are
normally changed to something suitable.

> The benefit are several:
> 
> - More eye balls: the underlying building is used and improved by many
> different platforms. Improvements in one affects all. A breakage here
> will be detected and fixed more rapidly.
> 

The underlying build is exactly the same for the prepatched toolchain.
It is only the download and patch process which has changed.

> - Freedom of access: anyone with commit access to SVN can fix or
> update the whole system, there is no dependency on a single person.
> 

No, you can't normally update the source of the packages.
You can add patches to any package, and this is possible
for the prepatched toolchain source.
It is an easy fix (which I am not against) to add a mirror anyway
where more people can update the ftp.

> - Less disk space consumed and bandwidth saved: Anyone building for
> more than one platform doesn't require additional 50Mb per toolchain.
> That's for all developers, everyone here has at least once built for a
> different $(ARCH) than they usually do.

No - I assume more disk space and more bandwidth consumed.
This is because the AVR32 users are a limited group.
My guess would be less than 5% of buildroot users build for AVR32.
The toolchain source needs to be downloaded *once* every time it is updated,
I.E: 1-2 times per year.

[DISKSPACE]
I do not see diskspace as a problem. If 50 MB is going to make or break
your build, you are in trouble anyway.
That is only theoretical, since gcc-4.2.2 is not a supported toolchain
in buildroot, so you will ONLY build this for the AVR32.

[BANDWIDTH USED]
According to my measurements the complete buildroot svn is 37,8 MB today.
The previous AVR32 patches increases the svn by 

gcc        0,7 Mb
uClibc    0,3 MB
gdb        3,0 MB
binutils   3,6 MB
---------------------
total        7,6 MB or an additional 20%.

This is to be multiplied with each toolchain version supported.
An AVR32 user which downloads the svn multiple times, 
quickly get past the point where they use more bandwidth
downloading the svn than they do downloading the prepatched source code.

[DOWNLOAD SPEED]
Worse is that you force ALL users to download the svn which will increase 
THEIR downloading time and will increase the loading on the server by 20%.

[DOWNLOAD COST]
I do not know about others, but I have 100 Mb Ethernet at home
and use a HSDPA/WCDMA modem when travelling, which cost $1-$15/MB
depending on where I am. 
I can usually reach a high speed/zero cost Internet connection within a week,
so I do not think that a delay for a toolchain package updated once or twice per year
is going to cause me that much trouble.

[SCALABILITY]
When you start to add new versions of the compiler the percentage
of the system will grow. There is a new binutils and new gdb
which are the main culprits. With support for the new toolchain
we would be close to 40% additions to the toolchain.

While you can purge older versions, this can cause problems
in itself, if a new toolchain will break on building certain packages.
The prepatched toolchain can support all toolchains very easily at low cost.

[DOWNLOAD SPEED]
I tried downloading AVR32 binutils from the current BR2_ATMEL_MIRROR 
(www.at91.com /pub/buildroot) and achieved 5 MB/seconds = 40 Mbit/second.
I can upload at 800 kB/second.

This was not using any internal connection.  Just a connection from home to Internet.
I doubt that this server should be too slow in the normal case.

> 
> - It worked: the external toolchain doesnt.
> 
> - Gives visibility to patches: If a patch breaks an $(ARCH) all you
> have to do is rename it, but you gain the knowleadge that the issue
> exists, and the patch maintainer can be notified. This makes it easier
> for patches to be accepted upstream later on.

Any patches applied in "target/device/Atmel/toolchains" will be visible as well.
Maybe they should be moved to "toolchain/gcc/<version>/prepatched/$(ARCH)"
or similar to highlight that the capability exists.
Obviously people seems unaware of the capability.

> - We could get rid of Atmel Specifics: In buildroot we have 2 flavors
> of external toolchain: generic and Atmel. Kill Atmel.
> 

I think the only real benefit of that is psychological.
The proper way of going mainstream, is for *Atmel* to go mainstream
by having AVR32 included in the mainstream toolchain downloads. 
Can't do too much about that I am afraid.

> Seriously, building an image takes several gigabytes, my dl dir has
> 1Gb of downloaded packages alone, when extracted they expand a lot,
> when compiled, another 2 fold, how significant is a few patches?
> 

It is a matter of pro's and con's.
I think the con's heavily outweighs the pros of adding the patches.
Especially for the non-AVR32 users.
I *AM* an AVR32 user myself but in this case, but I spent quite
some time pondering about the best approach of supporting
the AVR32 before adding the prepatched toolchain functionality.
I decided to show respect to the rights of the non-AVR32 users,
rather than carelessly try business as usual when it is unsuitable.

> Regards,
>    Thiago A. Correa
> _______________________________________________


Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/target/device/Atmel:atngw100 atngw100-base atngw100-expanded etc...

[Ulf Samuelsson]

> The ftp site seems to be out-of-date. The latest avr32 patches for gcc are
> for version 4.2.2 with atmel patch 1.0.8. I'm not sure about the others
> though. Also, they don't seem to be patched with the other uClibc patches as
> well, and there is no facility in buildroot to patch the pre-patched files
> either, as gcc 4.2.2 doesn't even have a toolchain directory. I've got
> pre-patched sources here: ftp://64.31.81.93 that includes avr32-atmel.1.0.8
> and all of the other uClibc patches as well. If you want to move them to the
> at91 site that would be great. A couple of us AVR32 users have been
> discussing the patch.avr32 scheme, is this out of the question?
> 
> Regards,
> John Voltz
> 

The Atmel stuff is uploaded, as mentioned in another email
Your patches are not included, so I am also uploading your gcc-4.2.2/4.2.3 with
the addition of the -uclibc extension (and removal of ".atmel").

Additional patches can be added in appropriate directories under 
"target/device/Atmel/toolchain".
If someone wants to move them to the "toolchain" tree,
that is OK with me.

Maybe "toolchain/gcc/4.2.2" has to be added as well.


Best Regards
Ulf Samuelsson