linux-kernel - Re: Working upstream toolchain for avr32?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8bd0f97a0712141323k7aae718ag4d0fd8a8f13d933f@mail.gmail.com>
Date:	Fri, 14 Dec 2007 16:23:12 -0500
From:	"Mike Frysinger" <vapier.adi@...il.com>
To:	"Robert Schwebel" <r.schwebel@...gutronix.de>
Cc:	"Adrian Bunk" <bunk@...nel.org>, hskinnemoen@...el.com,
	linux-kernel@...r.kernel.org
Subject: Re: Working upstream toolchain for avr32?

On Dec 14, 2007 3:55 PM, Robert Schwebel <r.schwebel@...gutronix.de> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/