AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
some patched binutils 2.17, and avr32 is currently the only architecture
in the kernel where upstream of both of them is not capable of building
a kernel for the architecture.
ALthough not technically a requirement, it would be nice if all Linux
kernel archs could be compiled with plain upstream toolchains.
Even more since at some point in the future [1] current toolchains might
no longer be able to compile the then current kernels.
Thanks in advance
Adrian
[1] although it might be a few years from now
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 13 Dec 2007 20:56:17 +0100
Adrian Bunk <[email protected]> wrote:
> AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
> some patched binutils 2.17, and avr32 is currently the only architecture
> in the kernel where upstream of both of them is not capable of building
> a kernel for the architecture.
gcc 4.2 is available from http://www.atmel.com. But I agree that it's
unfortunate that avr32 support isn't available upstream.
> ALthough not technically a requirement, it would be nice if all Linux
> kernel archs could be compiled with plain upstream toolchains.
We're working on it. I believe the legal issues around copyright
assignment, etc. are mostly sorted out now, so I'm hoping we'll start
pushing things upstream early next year.
> Even more since at some point in the future [1] current toolchains might
> no longer be able to compile the then current kernels.
I'm not sure if I understood that, but I guess it's always good to have
older versions of the toolchain around.
Haavard
On Thu, Dec 13, 2007 at 08:56:17PM +0100, Adrian Bunk wrote:
> AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
> some patched binutils 2.17, and avr32 is currently the only architecture
> in the kernel where upstream of both of them is not capable of building
> a kernel for the architecture.
Is an upstream toolchain available which is able to build blackfin?
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
On Dec 14, 2007 3:03 PM, Robert Schwebel <[email protected]> wrote:
> On Thu, Dec 13, 2007 at 08:56:17PM +0100, Adrian Bunk wrote:
> > AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
> > some patched binutils 2.17, and avr32 is currently the only architecture
> > in the kernel where upstream of both of them is not capable of building
> > a kernel for the architecture.
>
> Is an upstream toolchain available which is able to build blackfin?
binutils -- yes
uClibc -- yes (for FLAT)
gcc -- yes and no
we have some pieces in gcc, but if you want an
up-to-date-tested-known-working combination, you can fetch
sources/binaries from:
http://blackfin.uclinux.org/gf/project/toolchain/frs
we're working now to make sure that when gcc-4.3 is branched/released,
we're part of it
-mike
On Fri, Dec 14, 2007 at 03:21:45PM -0500, Mike Frysinger wrote:
> > Is an upstream toolchain available which is able to build blackfin?
>
> binutils -- yes
> uClibc -- yes (for FLAT)
> gcc -- yes and no
>
> we have some pieces in gcc, but if you want an
> up-to-date-tested-known-working combination, you can fetch
> sources/binaries from:
> http://blackfin.uclinux.org/gf/project/toolchain/frs
Upstream plus a well defined patch stack with well documented patches
would definitely be preferred here.
> we're working now to make sure that when gcc-4.3 is branched/released,
> we're part of it
Ah, that sounds pretty good! At the moment we still need three different
toolchains to build u-boot, the kernel and the icebear tools, which is
not very satisfying. An upstream-blessed toolchain would probably be
progress.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
On Dec 14, 2007 3:28 PM, Robert Schwebel <[email protected]> wrote:
> On Fri, Dec 14, 2007 at 03:21:45PM -0500, Mike Frysinger wrote:
> > > Is an upstream toolchain available which is able to build blackfin?
> >
> > binutils -- yes
> > uClibc -- yes (for FLAT)
> > gcc -- yes and no
> >
> > we have some pieces in gcc, but if you want an
> > up-to-date-tested-known-working combination, you can fetch
> > sources/binaries from:
> > http://blackfin.uclinux.org/gf/project/toolchain/frs
>
> Upstream plus a well defined patch stack with well documented patches
> would definitely be preferred here.
as you've been told in the past, the things are documented. go read
the ChangeLog.bfin file.
> > we're working now to make sure that when gcc-4.3 is branched/released,
> > we're part of it
>
> Ah, that sounds pretty good! At the moment we still need three different
> toolchains to build u-boot, the kernel
maybe, if you're using different version of u-boot and the kernel.
but that isnt a good idea anyways.
> and the icebear tools, which is not very satisfying.
there's nothing we can do about this and you're complaining to the
wrong people. icebear is a third party binary-only tool. if you dont
like the way the third party does things, complain to the third party.
or dont buy their product.
> An upstream-blessed toolchain would probably be
> progress.
we are upstream and we've given you blessed toolchains.
-mike
On Fri, Dec 14, 2007 at 03:35:36PM -0500, Mike Frysinger wrote:
> > Upstream plus a well defined patch stack with well documented patches
> > would definitely be preferred here.
Well, tell me that it is wrong, but isn't it common community
methodology to have rebasable things like patch stacks or git trees
against mainline instead of disconnected vendor trees?
> as you've been told in the past, the things are documented. go read
> the ChangeLog.bfin file.
You didn't explain how for example your trunk [1] is related to mainline
[2].
> > Ah, that sounds pretty good! At the moment we still need three different
> > toolchains to build u-boot, the kernel
>
> maybe, if you're using different version of u-boot and the kernel.
> but that isnt a good idea anyways.
We use mainline linux and u-boot-v2, which is surely not what ADI
supplies officially to their random commercial customers. Nevertheless,
it is the way community technology works elsewhere.
> > and the icebear tools, which is not very satisfying.
>
> there's nothing we can do about this and you're complaining to the
> wrong people. icebear is a third party binary-only tool.
Hmm, the sources are here: http://www.section5.ch/dsp/icebear/bfloader-1.2.tgz
Do you have a good hint for a better low level debug tool? For all other
processors like ARM, PowerPC and ColdFire we use a BDI2000, but it seems
not to be available for blackfin.
> if you dont like the way the third party does things, complain to
> the third party. or dont buy their product.
Thanks for the constructive comments.
> we are upstream and we've given you blessed toolchains.
"Trust us, we are $BIG_VENDOR" is not the way these things are usually
done. Sorry, I don't buy this. Chip vendors just too often lose interest
in supporting their users once they have moved to the next generations
of chips or whatever.
Can you explain why bfin should not have gcc.gnu.org as it's upstream?
Robert
[1] http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2F
[2] http://gcc.gnu.org/viewcvs/trunk/
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
On Dec 14, 2007 3:55 PM, Robert Schwebel <[email protected]> wrote:
> On Fri, Dec 14, 2007 at 03:35:36PM -0500, Mike Frysinger wrote:
> > > Upstream plus a well defined patch stack with well documented patches
> > > would definitely be preferred here.
>
> Well, tell me that it is wrong, but isn't it common community
> methodology to have rebasable things like patch stacks or git trees
> against mainline instead of disconnected vendor trees?
it depends on the community. both methods are quite common.
> > as you've been told in the past, the things are documented. go read
> > the ChangeLog.bfin file.
>
> You didn't explain how for example your trunk [1] is related to mainline
> [2].
nano `find -name ChangeLog.bfin`
read the ChangeLog and the associated commit. this is exactly the
same way gcc works. you want to know what changed for ChangeLog entry
$foo, you look at the commit surrounding it.
> > > Ah, that sounds pretty good! At the moment we still need three different
> > > toolchains to build u-boot, the kernel
> >
> > maybe, if you're using different version of u-boot and the kernel.
> > but that isnt a good idea anyways.
>
> We use mainline linux and u-boot-v2, which is surely not what ADI
> supplies officially to their random commercial customers. Nevertheless,
> it is the way community technology works elsewhere.
i dont know what "u-boot-v2" is, but if you're referring to mainline
u-boot, then it too is not in a usable state. it isnt just random
commercial customers as we support anyone using a Blackfin (students,
hobbyists, whoever). but only if they're using the same source base
we've tested. once we finish moving things to mainline, that will
become our source base. until then, it is not supportable.
> > > and the icebear tools, which is not very satisfying.
> >
> > there's nothing we can do about this and you're complaining to the
> > wrong people. icebear is a third party binary-only tool.
>
> Hmm, the sources are here: http://www.section5.ch/dsp/icebear/bfloader-1.2.tgz
*some* of the sources. icebear requires usage of binary blobs in
there to communicate with their USB JTAG.
> Do you have a good hint for a better low level debug tool? For all other
> processors like ARM, PowerPC and ColdFire we use a BDI2000, but it seems
> not to be available for blackfin.
there are parallel port jtags available for cheap as well as an
ethernet solution. links can be found in the Blackfin docs wiki.
> > if you dont like the way the third party does things, complain to
> > the third party. or dont buy their product.
>
> Thanks for the constructive comments.
they are constructive and quite in the open source spirit. if you
dont like dealing with binary blobs, then dont complain to people who
can literally do noting about it, do something yourself about it. put
your money where your mouth is.
> > we are upstream and we've given you blessed toolchains.
>
> "Trust us, we are $BIG_VENDOR" is not the way these things are usually
> done. Sorry, I don't buy this. Chip vendors just too often lose interest
> in supporting their users once they have moved to the next generations
> of chips or whatever.
<insert generalities about "big corporations here" and assume everyone
is the same. it's easier when making assumptions that way!>
> Can you explain why bfin should not have gcc.gnu.org as it's upstream?
as you've been told multiple times, that is where we are heading.
asking the same question multiple times but expecting a different
response is the definition of madness is it not ?
-mike
On Fri, Dec 14, 2007 at 04:23:12PM -0500, Mike Frysinger wrote:
> > You didn't explain how for example your trunk [1] is related to mainline
> > [2].
>
> nano `find -name ChangeLog.bfin`
>
> read the ChangeLog and the associated commit. this is exactly the
> same way gcc works. you want to know what changed for ChangeLog entry
> $foo, you look at the commit surrounding it.
Well, it's your decision how you think you'd best manage your changes.
It's just an observation that bfin toolchains are a parrallel universe
for community people being used to the "mainline + reviewable patch
sets" paradigm (no, the svn is not reviewable, as it is not regularly
rebased against upstream).
> i dont know what "u-boot-v2" is, but if you're referring to mainline
> u-boot, then it too is not in a usable state.
No need to continue this discussion here. I'll come back with real
questions when re-testing u2 with your "official" toolchains.
> it isnt just random commercial customers as we support anyone using a
> Blackfin (students, hobbyists, whoever). but only if they're using
> the same source base we've tested. once we finish moving things to
> mainline, that will become our source base. until then, it is not
> supportable.
That's all I wanted to hear. As long as you are heading towards getting
the code into gcc.gnu.org, I don't care any more.
> <insert generalities about "big corporations here" and assume everyone
> is the same. it's easier when making assumptions that way!>
Well, chip vendors are usually not that much of a constant as people
from the industry might wish. Strategies change, products are
discontinued, focus changes, companies are sold etc. For industrial
users who go the open source way because of long term product
strategies, having control over the source is pretty important. And
experience shows that once you have problems, the community is a much
better source of help than vendors.
> > Can you explain why bfin should not have gcc.gnu.org as it's upstream?
>
> as you've been told multiple times, that is where we are heading.
> asking the same question multiple times but expecting a different
> response is the definition of madness is it not?
Thanks for clarification. Regarding the original post, it justifies my
assumption that blackfin is currently not supported by upstream gcc.
rsc
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
On Fri, Dec 14, 2007 at 10:41:58AM +0100, Haavard Skinnemoen wrote:
> On Thu, 13 Dec 2007 20:56:17 +0100
> Adrian Bunk <[email protected]> wrote:
>
> > AFAIK the latest available AVR32 toolchains are some patched gcc 4.0 and
> > some patched binutils 2.17, and avr32 is currently the only architecture
> > in the kernel where upstream of both of them is not capable of building
> > a kernel for the architecture.
>
> gcc 4.2 is available from http://www.atmel.com. But I agree that it's
> unfortunate that avr32 support isn't available upstream.
>
> > ALthough not technically a requirement, it would be nice if all Linux
> > kernel archs could be compiled with plain upstream toolchains.
>
> We're working on it. I believe the legal issues around copyright
> assignment, etc. are mostly sorted out now, so I'm hoping we'll start
> pushing things upstream early next year.
First of all sorry for my late answer.
What you are saying is more or less what I was hoping to hear. :)
> > Even more since at some point in the future [1] current toolchains might
> > no longer be able to compile the then current kernels.
>
> I'm not sure if I understood that, but I guess it's always good to have
> older versions of the toolchain around.
My point was that if there was _only_ support in some older toolchain,
a few years from now there might no longer be a toolchain capable of
compiling the then-current kernel.
> Haavard
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed