[Buildroot] [Patch] internal toolchain for avr32

[Buildroot] [Patch] internal toolchain for avr32

[Benjamin Tietz]

Hi,

I added some patches and support for the avr32-architecture using the
internal toolchain.
Support for Linux 2.6.20, gcc 4.1.2 and uclibc 0.9.29.
I hope i didn't missed a thing in the patch.

It (~600kB) can be found under
http://www.micronet24.de/pub/avr32-internal-toolchain.patch.bz2

regards
Benjamin

PS: I don't like the idea of prepatched sources, since I'm compiling for
multiple architectures this would really increase the amount of data to
download

[Buildroot] [Patch] internal toolchain for avr32

[Benjamin Tietz]

Since my revision wasn't the latest, I didn't got the nice mud ulf
created with his vendor-supplied toolchain. I'm sorry.

attached a patch that revert that misconfiguration.

@Ulf: Not everybody is happy about a vendor-supplied toolchain! So at
least give everybody the chance to decide whether to use it or not.
It would help even more, if Atmel would give external developers access
to their patches; those from avr32linux.org becoming older more and more
whilest pointing to download everything in ONE packet from Atmel. Thats
a really big download...
And another thing to add: get your vendor-specific stuff out of the
general Makefiles and Config.ins (it even would be nice if you could use
the default names; it would make searching through them much easier).
There are ways to do that. the vendor can redifine nearly all vars in
their own Makefiles; including default download-locations. And adding
additional patches isn't that difficult too. See the Makefile.in in
target/device/Atmel/avr32patches in my patch.

best regards
Benjamin

On Mon, Aug 06, 2007 at 10:32:29AM +0200, Benjamin Tietz wrote:
> Hi,
> 
> I added some patches and support for the avr32-architecture using the
> internal toolchain.
> Support for Linux 2.6.20, gcc 4.1.2 and uclibc 0.9.29.
> I hope i didn't missed a thing in the patch.
> 
> It (~600kB) can be found under
> http://www.micronet24.de/pub/avr32-internal-toolchain.patch.bz2
> 
> regards
> Benjamin
> 
> PS: I don't like the idea of prepatched sources, since I'm compiling for
> multiple architectures this would really increase the amount of data to
> download
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: revert_vendor-config.patch
Type: text/x-diff
Size: 5051 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070806/c6e9296d/attachment.bin 

[Buildroot] [Patch] internal toolchain for avr32

[Ulf Samuelsson]

> Since my revision wasn't the latest, I didn't got the nice mud ulf
> created with his vendor-supplied toolchain. I'm sorry.
> 
> attached a patch that revert that misconfiguration.
> 
> @Ulf: Not everybody is happy about a vendor-supplied toolchain! So at
> least give everybody the chance to decide whether to use it or not.

I am not happy about doubling the size of buildroot just because
the "configure" files are patched by the avr32 patches.
That is why I did it this way.
I believe that the buildroot stuff will be downloaded many times
and the toolchain only once.
If there are modifications later, then they will most likely be patches
against the prepatched toolset.

> It would help even more, if Atmel would give external developers access
> to their patches; those from avr32linux.org becoming older more and more
> whilest pointing to download everything in ONE packet from Atmel. Thats
> a really big download...

Download the stuff from buildroot and diff against vanilla + buildroot patches and you have it.
If you have a slow line, then you can probably get access to a fast line somewhere else
to download it once.

While I work for Atmel, I am not in the AVR32 product line.
The product line guys makes decisions what to publish, - I don't.

> And another thing to add: get your vendor-specific stuff out of the
> general Makefiles and Config.ins (it even would be nice if you could use

I did...
Now it is a generalized framework allowing anyone to add 
a prepatched framework by setting the VENDOR_* stuff.

In target/device you select which vendor. Obviously only Atmel available now
but others can be added.
For most architecture, there is already support in the gcc toolchain
so using a prepatched toolchain is not a good idea.
When AVR32 will get merged, then I think it is the time
to adopt the normal method.

> the default names; it would make searching through them much easier).

> There are ways to do that. the vendor can redifine nearly all vars in
> their own Makefiles; including default download-locations. And adding
> additional patches isn't that difficult too. See the Makefile.in in
> target/device/Atmel/avr32patches in my patch.

You have to consider visibility.
The target/device stuff is not included until *after* the toolchain has been read in
so you can't change the download location of gcc etc. as far as I understand.


Best Regards
Ulf Samuelsson

[Buildroot] [Patch] internal toolchain for avr32

[Ulf Samuelsson]

> Since my revision wasn't the latest, I didn't got the nice mud ulf
> created with his vendor-supplied toolchain. I'm sorry.
> 
> attached a patch that revert that misconfiguration.
> 
> @Ulf: Not everybody is happy about a vendor-supplied toolchain! So at
> least give everybody the chance to decide whether to use it or not.

Your patch does not give everyone a chance to use it or not.
It *removes* the possibility to use the vendor prepatched toolchain.

If you are keen on not downloading that toolchain, then
a proper patch to buildroot would put the AVR32 patches you generated 
on a server somewhere and then download the patch before applying to the gcc/binutils/gdb/uClibc.
Obviously, you would have to keep track of the development of the AVR32
toolchain and update when neccessary.

Best Regards
Ulf Samuelsson 

[Buildroot] [Patch] internal toolchain for avr32

[Hans-Christian Egtvedt]

On Mon, 2007-08-06 at 22:58 +0200, Ulf Samuelsson wrote:
> > Since my revision wasn't the latest, I didn't got the nice mud ulf
> > created with his vendor-supplied toolchain. I'm sorry.
> > 
> > attached a patch that revert that misconfiguration.
> > 
> > @Ulf: Not everybody is happy about a vendor-supplied toolchain! So at
> > least give everybody the chance to decide whether to use it or not.
> 
> I am not happy about doubling the size of buildroot just because
> the "configure" files are patched by the avr32 patches.
> That is why I did it this way.
> I believe that the buildroot stuff will be downloaded many times
> and the toolchain only once.
> If there are modifications later, then they will most likely be patches
> against the prepatched toolset.

You do not double the size of buildroot, you add roughly 600 kB to the
compressed size.

> > It would help even more, if Atmel would give external developers access
> > to their patches; those from avr32linux.org becoming older more and more
> > whilest pointing to download everything in ONE packet from Atmel. Thats
> > a really big download...
> 
> Download the stuff from buildroot and diff against vanilla + buildroot patches and you have it.
> If you have a slow line, then you can probably get access to a fast line somewhere else
> to download it once.

I do not really understand the crisis if buildroot grows a bit (until
patches are upstream, etc). My download folder is 350 MB, which is some
magnitudes larger than buildroot. The user will have to wait for all the
other source files to download anyway.

> While I work for Atmel, I am not in the AVR32 product line.
> The product line guys makes decisions what to publish, - I don't.

The patches on avr32linux.org for the toolchain should be the latest,
but they are actually quite some off. I will prod to see what the
intention about the patch pages are.

The problem with GCC and binutils is that the configure scripts have to
be regenerated, and thus producing an enormous diff :/

<cut>

-- 
With kind regards,
Hans-Christian Egtvedt, Applications Engineer