[U-Boot] [ANN] U-Boot v2015.07 released

[U-Boot] [ANN] U-Boot v2015.07 released

[Tom Rini]

Hey all,

I've pushed v2015.07 out to the repository and tarballs should exist
soon.

This sounds a bit like a broken record, but it's true.  The Kconfig
migration and DM work continue moving along.

Looking over the announcement for v2015.04, I see I said we'd deprecate
MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
right after the tag.  If buildman isn't working for you and your use
case, we really need to talk.

Finally, I would encourage custodians to follow-up with anything big I've
overlooked.

Thanks for the hard work everyone!  The merge window is now open and
will close on Saturday Aug 1st.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/965ee4e8/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.07 released

[Stephen Warren]

On 07/14/2015 11:56 AM, Tom Rini wrote:
> Hey all,
>
> I've pushed v2015.07 out to the repository and tarballs should exist
> soon.
>
> This sounds a bit like a broken record, but it's true.  The Kconfig
> migration and DM work continue moving along.
>
> Looking over the announcement for v2015.04, I see I said we'd deprecate
> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> right after the tag.  If buildman isn't working for you and your use
> case, we really need to talk.

The nice thing about MAKEALL was that I could simply grab a source tree, 
and run the following to build in-tree:

CROSS_COMPILE=something ./MAKEALL foo

However, with buildman, some complex config file needed to be set up to 
configure the toolchain (and I could never parse the docs to work out 
how to create it in a new checkout), plus it made copies of the source 
tree which takes ages for me.

Is there an equivalently simple way to invoke buildman that doesn't 
require configuration and copying?

[U-Boot] [ANN] U-Boot v2015.07 released

[Peter Robinson]

Hi Tom,

On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote:
> Hey all,
>
> I've pushed v2015.07 out to the repository and tarballs should exist
> soon.

I don't see the release tag in git either by doing a pull from my
checkout or via the web interface. Does it take time to sync?

Peter

> This sounds a bit like a broken record, but it's true.  The Kconfig
> migration and DM work continue moving along.
>
> Looking over the announcement for v2015.04, I see I said we'd deprecate
> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> right after the tag.  If buildman isn't working for you and your use
> case, we really need to talk.
>
> Finally, I would encourage custodians to follow-up with anything big I've
> overlooked.
>
> Thanks for the hard work everyone!  The merge window is now open and
> will close on Saturday Aug 1st.
>
> --
> Tom
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [ANN] U-Boot v2015.07 released

[Nikolay Dimitrov]

Hi Tom,

On 07/14/2015 11:14 PM, Peter Robinson wrote:
> Hi Tom,
>
> On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote:
>> Hey all,
>>
>> I've pushed v2015.07 out to the repository and tarballs should exist
>> soon.
>
> I don't see the release tag in git either by doing a pull from my
> checkout or via the web interface. Does it take time to sync?
>
> Peter

Same here, the release tag is missing.

Kind regards,
Nikolay

[U-Boot] [ANN] U-Boot v2015.07 released

[Robert Nelson]

On Tue, Jul 14, 2015 at 3:24 PM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Hi Tom,
>
> On 07/14/2015 11:14 PM, Peter Robinson wrote:
>>
>> Hi Tom,
>>
>> On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote:
>>>
>>> Hey all,
>>>
>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>> soon.
>>
>>
>> I don't see the release tag in git either by doing a pull from my
>> checkout or via the web interface. Does it take time to sync?
>>
>> Peter
>
>
> Same here, the release tag is missing.

The public repo is on a 6 hour cron job, give it a few more hours..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

[U-Boot] [ANN] U-Boot v2015.07 released

[Tom Rini]

On Tue, Jul 14, 2015 at 11:24:52PM +0300, Nikolay Dimitrov wrote:
> Hi Tom,
> 
> On 07/14/2015 11:14 PM, Peter Robinson wrote:
> >Hi Tom,
> >
> >On Tue, Jul 14, 2015 at 6:56 PM, Tom Rini <trini@konsulko.com> wrote:
> >>Hey all,
> >>
> >>I've pushed v2015.07 out to the repository and tarballs should exist
> >>soon.
> >
> >I don't see the release tag in git either by doing a pull from my
> >checkout or via the web interface. Does it take time to sync?
> >
> >Peter
> 
> Same here, the release tag is missing.

Yes, there is a delay between push and sync to git.denx.de.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/91ea3533/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.07 released

[Tom Rini]

On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> On 07/14/2015 11:56 AM, Tom Rini wrote:
> >Hey all,
> >
> >I've pushed v2015.07 out to the repository and tarballs should exist
> >soon.
> >
> >This sounds a bit like a broken record, but it's true.  The Kconfig
> >migration and DM work continue moving along.
> >
> >Looking over the announcement for v2015.04, I see I said we'd deprecate
> >MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> >right after the tag.  If buildman isn't working for you and your use
> >case, we really need to talk.
> 
> The nice thing about MAKEALL was that I could simply grab a source
> tree, and run the following to build in-tree:
> 
> CROSS_COMPILE=something ./MAKEALL foo
> 
> However, with buildman, some complex config file needed to be set up
> to configure the toolchain (and I could never parse the docs to work
> out how to create it in a new checkout), plus it made copies of the
> source tree which takes ages for me.
> 
> Is there an equivalently simple way to invoke buildman that doesn't
> require configuration and copying?

For no copying, --in-tree does what you want I think.  For not
configuring a toolchain, there's two ways to go about this.  One would
be to do something like:

diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index e33e105..bba60d5 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -159,7 +159,7 @@ class Toolchains:
                  " to your buildman config file %s. See README for details" %
                  bsettings.config_fname)
 
-        paths = []
+        paths = ['/usr', '/usr/local']
         for name, value in toolchains:
             if '*' in value:
                 paths += glob.glob(value)

And then any toolchains in /usr and /usr/local would be picked up and
used.  Another option would be to add --tool-chain-path DIR and throw
that into the above function.  Thoughts?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/bebcb3a0/attachment.sig>

[U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released)

[Stephen Warren]

On 07/14/2015 04:09 PM, Tom Rini wrote:
> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>> Hey all,
>>>
>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>> soon.
>>>
>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>> migration and DM work continue moving along.
>>>
>>> Looking over the announcement for v2015.04, I see I said we'd deprecate
>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>> right after the tag.  If buildman isn't working for you and your use
>>> case, we really need to talk.
>>
>> The nice thing about MAKEALL was that I could simply grab a source
>> tree, and run the following to build in-tree:
>>
>> CROSS_COMPILE=something ./MAKEALL foo
>>
>> However, with buildman, some complex config file needed to be set up
>> to configure the toolchain (and I could never parse the docs to work
>> out how to create it in a new checkout), plus it made copies of the
>> source tree which takes ages for me.
>>
>> Is there an equivalently simple way to invoke buildman that doesn't
>> require configuration and copying?
>
> For no copying, --in-tree does what you want I think.

OK. Making that the default would be useful, or providing a buildman 
wrapper script in the root directory that always passes this option.

> For not
> configuring a toolchain, there's two ways to go about this.  One would
> be to do something like:
>
> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> index e33e105..bba60d5 100644
> --- a/tools/buildman/toolchain.py
> +++ b/tools/buildman/toolchain.py
> @@ -159,7 +159,7 @@ class Toolchains:
>                    " to your buildman config file %s. See README for details" %
>                    bsettings.config_fname)
>
> -        paths = []
> +        paths = ['/usr', '/usr/local']
>           for name, value in toolchains:
>               if '*' in value:
>                   paths += glob.glob(value)
>
> And then any toolchains in /usr and /usr/local would be picked up and
> used.  Another option would be to add --tool-chain-path DIR and throw
> that into the above function.  Thoughts?

Does that find cross-compilers? IIRC I had to add the full compiler 
binary name into the config file, not just a /usr search directory, so I 
don't think the above patch is enough to make it work. What if I want to 
use a specific cross-compiler and I have 4 different ARM compilers 
installed in /usr? How would it know which architecture's cross-compiler 
to use?

I like the interface of just setting the CROSS_COMPILE variable, since I 
can just set it in the environment and forget it if I want. Perhaps 
buildman could just use it if it was set, and ignore the config file (or 
again, a simple wrapper script could do that)?

[U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released)

[Simon Glass]

Hi Stephen,

On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> wrote:
>
> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>
>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>
>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>
>>>> Hey all,
>>>>
>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>> soon.
>>>>
>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>> migration and DM work continue moving along.
>>>>
>>>> Looking over the announcement for v2015.04, I see I said we'd deprecate
>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>> right after the tag.  If buildman isn't working for you and your use
>>>> case, we really need to talk.
>>>
>>>
>>> The nice thing about MAKEALL was that I could simply grab a source
>>> tree, and run the following to build in-tree:
>>>
>>> CROSS_COMPILE=something ./MAKEALL foo
>>>
>>> However, with buildman, some complex config file needed to be set up
>>> to configure the toolchain (and I could never parse the docs to work
>>> out how to create it in a new checkout), plus it made copies of the
>>> source tree which takes ages for me.
>>>
>>> Is there an equivalently simple way to invoke buildman that doesn't
>>> require configuration and copying?
>>
>>
>> For no copying, --in-tree does what you want I think.
>
>
> OK. Making that the default would be useful, or providing a buildman wrapper script in the root directory that always passes this option.

$ buildman seaboard

will build U-Boot for seaboard. It does not copy the git tree. It puts
the output in ../current, or some other directory of your choosing. I
think that's pretty convenient.

For toolchains you can use

$ buildman --fetch-arch arm

to get a default one and set it up ready for use complete with config
file. But honestly the config file is not that hard to figure out!

>
>> For not
>> configuring a toolchain, there's two ways to go about this.  One would
>> be to do something like:
>>
>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>> index e33e105..bba60d5 100644
>> --- a/tools/buildman/toolchain.py
>> +++ b/tools/buildman/toolchain.py
>> @@ -159,7 +159,7 @@ class Toolchains:
>>                    " to your buildman config file %s. See README for details" %
>>                    bsettings.config_fname)
>>
>> -        paths = []
>> +        paths = ['/usr', '/usr/local']
>>           for name, value in toolchains:
>>               if '*' in value:
>>                   paths += glob.glob(value)
>>
>> And then any toolchains in /usr and /usr/local would be picked up and
>> used.  Another option would be to add --tool-chain-path DIR and throw
>> that into the above function.  Thoughts?
>
>
> Does that find cross-compilers? IIRC I had to add the full compiler binary name into the config file, not just a /usr search directory, so I don't think the above patch is enough to make it work. What if I want to use a specific cross-compiler and I have 4 different ARM compilers installed in /usr? How would it know which architecture's cross-compiler to use?
>
> I like the interface of just setting the CROSS_COMPILE variable, since I can just set it in the environment and forget it if I want. Perhaps buildman could just use it if it was set, and ignore the config file (or again, a simple wrapper script could do that)?

That would work for building a single arch. We could perhaps add an
option for that. But full multi-toolchain support is something that
would be nice to add to buildman, if someone has time.

Regards,
Simon

[U-Boot] simple buildman usage

[Stephen Warren]

On 07/14/2015 05:07 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>
>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>
>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>
>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>
>>>>> Hey all,
>>>>>
>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>> soon.
>>>>>
>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>> migration and DM work continue moving along.
>>>>>
>>>>> Looking over the announcement for v2015.04, I see I said we'd deprecate
>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>> case, we really need to talk.
>>>>
>>>>
>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>> tree, and run the following to build in-tree:
>>>>
>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>
>>>> However, with buildman, some complex config file needed to be set up
>>>> to configure the toolchain (and I could never parse the docs to work
>>>> out how to create it in a new checkout), plus it made copies of the
>>>> source tree which takes ages for me.
>>>>
>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>> require configuration and copying?
>>>
>>>
>>> For no copying, --in-tree does what you want I think.
>>
>>
>> OK. Making that the default would be useful, or providing a buildman wrapper script in the root directory that always passes this option.
>
> $ buildman seaboard
>
> will build U-Boot for seaboard. It does not copy the git tree. It puts
> the output in ../current, or some other directory of your choosing. I
> think that's pretty convenient.

I'd prefer it to go in . so I don't get clutter outside my working tree.

> For toolchains you can use
>
> $ buildman --fetch-arch arm
>
> to get a default one and set it up ready for use complete with config
> file.

I already have the toolchain I want to use installed, so I'd like a 
simple way to use it.

> But honestly the config file is not that hard to figure out!

Well perhaps if you understand its concepts/semantics, but I've always 
had an extremely hard time grasping it, and at least the last time I 
RTFMd there weren't any examples aimed at "this is how to write a config 
file to just use this binary name in $PATH". Equally, having to edit a 
config file any time I want to switch compilers is a bit annoying.

[U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released)

[Tom Rini]

On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> On 07/14/2015 04:09 PM, Tom Rini wrote:
> >On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> >>On 07/14/2015 11:56 AM, Tom Rini wrote:
> >>>Hey all,
> >>>
> >>>I've pushed v2015.07 out to the repository and tarballs should exist
> >>>soon.
> >>>
> >>>This sounds a bit like a broken record, but it's true.  The Kconfig
> >>>migration and DM work continue moving along.
> >>>
> >>>Looking over the announcement for v2015.04, I see I said we'd deprecate
> >>>MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> >>>right after the tag.  If buildman isn't working for you and your use
> >>>case, we really need to talk.
> >>
> >>The nice thing about MAKEALL was that I could simply grab a source
> >>tree, and run the following to build in-tree:
> >>
> >>CROSS_COMPILE=something ./MAKEALL foo
> >>
> >>However, with buildman, some complex config file needed to be set up
> >>to configure the toolchain (and I could never parse the docs to work
> >>out how to create it in a new checkout), plus it made copies of the
> >>source tree which takes ages for me.
> >>
> >>Is there an equivalently simple way to invoke buildman that doesn't
> >>require configuration and copying?
> >
> >For no copying, --in-tree does what you want I think.
> 
> OK. Making that the default would be useful, or providing a buildman
> wrapper script in the root directory that always passes this option.
> 
> >For not
> >configuring a toolchain, there's two ways to go about this.  One would
> >be to do something like:
> >
> >diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> >index e33e105..bba60d5 100644
> >--- a/tools/buildman/toolchain.py
> >+++ b/tools/buildman/toolchain.py
> >@@ -159,7 +159,7 @@ class Toolchains:
> >                   " to your buildman config file %s. See README for details" %
> >                   bsettings.config_fname)
> >
> >-        paths = []
> >+        paths = ['/usr', '/usr/local']
> >          for name, value in toolchains:
> >              if '*' in value:
> >                  paths += glob.glob(value)
> >
> >And then any toolchains in /usr and /usr/local would be picked up and
> >used.  Another option would be to add --tool-chain-path DIR and throw
> >that into the above function.  Thoughts?
> 
> Does that find cross-compilers? IIRC I had to add the full compiler
> binary name into the config file, not just a /usr search directory,
> so I don't think the above patch is enough to make it work. What if
> I want to use a specific cross-compiler and I have 4 different ARM
> compilers installed in /usr? How would it know which architecture's
> cross-compiler to use?

Well, how much are you expecting to Just Work without making a real
config?  That much does work for finding cross tools installed into
those paths.  But if you have > 1 architecture toolchain in a
single location buildman does fail there today.

> I like the interface of just setting the CROSS_COMPILE variable,
> since I can just set it in the environment and forget it if I want.
> Perhaps buildman could just use it if it was set, and ignore the
> config file (or again, a simple wrapper script could do that)?

I do not want a wrapper script.  Trying to make one thing act like
another thing leads to madness and corner cases.  That said, how hard
would it be to have buildman see if CROSS_COMPILE is set and in turn
force that to be used for all specified build targets?  I thought about
making it see what the value is and then heuristic which arch to use,
but I think that's more error prone than perhaps buildman
--default-tool-chain (Uses passed value or CROSS_COMPILE if set in env)
?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/d15ab949/attachment.sig>

[U-Boot] simple buildman usage

[Tom Rini]

On Tue, Jul 14, 2015 at 05:27:15PM -0600, Stephen Warren wrote:
> On 07/14/2015 05:07 PM, Simon Glass wrote:
[snip]
> Equally,
> having to edit a config file any time I want to switch compilers is
> a bit annoying.

As I have a wrapper to go and whack a specific value into the builmanrc
I pass via -G so that I can use ELDK 5.2 or 5.3 or Linaro's whatever
release or so on, +1 to it being annoying to have to edit a file to
switch compilers.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150714/4a109341/attachment.sig>

[U-Boot] simple buildman usage

[Simon Glass]

Hi Stephen,

On 14 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/14/2015 05:07 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>>
>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>
>>>>
>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>
>>>>>
>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>> soon.
>>>>>>
>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>> migration and DM work continue moving along.
>>>>>>
>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>> deprecate
>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>> case, we really need to talk.
>>>>>
>>>>>
>>>>>
>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>> tree, and run the following to build in-tree:
>>>>>
>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>
>>>>> However, with buildman, some complex config file needed to be set up
>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>> source tree which takes ages for me.
>>>>>
>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>> require configuration and copying?
>>>>
>>>>
>>>>
>>>> For no copying, --in-tree does what you want I think.
>>>
>>>
>>>
>>> OK. Making that the default would be useful, or providing a buildman
>>> wrapper script in the root directory that always passes this option.
>>
>>
>> $ buildman seaboard
>>
>> will build U-Boot for seaboard. It does not copy the git tree. It puts
>> the output in ../current, or some other directory of your choosing. I
>> think that's pretty convenient.
>
>
> I'd prefer it to go in . so I don't get clutter outside my working tree.

-o .

>
>> For toolchains you can use
>>
>> $ buildman --fetch-arch arm
>>
>> to get a default one and set it up ready for use complete with config
>> file.
>
>
> I already have the toolchain I want to use installed, so I'd like a simple
> way to use it.
>
>> But honestly the config file is not that hard to figure out!
>
>
> Well perhaps if you understand its concepts/semantics, but I've always had
> an extremely hard time grasping it, and at least the last time I RTFMd there
> weren't any examples aimed at "this is how to write a config file to just
> use this binary name in $PATH". Equally, having to edit a config file any
> time I want to switch compilers is a bit annoying.

Agreed. Perhaps annoying enough to contribute a patch?

Regards,
Simon

[U-Boot] [ANN] U-Boot v2015.07 released

[Wolfgang Denk]

Dear Tom,

In message <20150714175627.GJ23886@bill-the-cat> you wrote:
> 
> I've pushed v2015.07 out to the repository and tarballs should exist
> soon.

Tarballs are both on the ACD [1] and the FTP server [2].

[1] https://www.amazon.com/clouddrive/share/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9edV1PB8?ref_=cd_share_link_copy
[2] ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2

Thanks!


Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
backups: always in season, never out of style.

[U-Boot] simple buildman usage (was: Re: [ANN] U-Boot v2015.07 released)

[Simon Glass]

Hi Tom,

On 14 July 2015 at 17:33, Tom Rini <trini@konsulko.com> wrote:
>
> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> > On 07/14/2015 04:09 PM, Tom Rini wrote:
> > >On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> > >>On 07/14/2015 11:56 AM, Tom Rini wrote:
> > >>>Hey all,
> > >>>
> > >>>I've pushed v2015.07 out to the repository and tarballs should exist
> > >>>soon.
> > >>>
> > >>>This sounds a bit like a broken record, but it's true.  The Kconfig
> > >>>migration and DM work continue moving along.
> > >>>
> > >>>Looking over the announcement for v2015.04, I see I said we'd deprecate
> > >>>MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> > >>>right after the tag.  If buildman isn't working for you and your use
> > >>>case, we really need to talk.
> > >>
> > >>The nice thing about MAKEALL was that I could simply grab a source
> > >>tree, and run the following to build in-tree:
> > >>
> > >>CROSS_COMPILE=something ./MAKEALL foo
> > >>
> > >>However, with buildman, some complex config file needed to be set up
> > >>to configure the toolchain (and I could never parse the docs to work
> > >>out how to create it in a new checkout), plus it made copies of the
> > >>source tree which takes ages for me.
> > >>
> > >>Is there an equivalently simple way to invoke buildman that doesn't
> > >>require configuration and copying?
> > >
> > >For no copying, --in-tree does what you want I think.
> >
> > OK. Making that the default would be useful, or providing a buildman
> > wrapper script in the root directory that always passes this option.
> >
> > >For not
> > >configuring a toolchain, there's two ways to go about this.  One would
> > >be to do something like:
> > >
> > >diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> > >index e33e105..bba60d5 100644
> > >--- a/tools/buildman/toolchain.py
> > >+++ b/tools/buildman/toolchain.py
> > >@@ -159,7 +159,7 @@ class Toolchains:
> > >                   " to your buildman config file %s. See README for details" %
> > >                   bsettings.config_fname)
> > >
> > >-        paths = []
> > >+        paths = ['/usr', '/usr/local']
> > >          for name, value in toolchains:
> > >              if '*' in value:
> > >                  paths += glob.glob(value)
> > >
> > >And then any toolchains in /usr and /usr/local would be picked up and
> > >used.  Another option would be to add --tool-chain-path DIR and throw
> > >that into the above function.  Thoughts?
> >
> > Does that find cross-compilers? IIRC I had to add the full compiler
> > binary name into the config file, not just a /usr search directory,
> > so I don't think the above patch is enough to make it work. What if
> > I want to use a specific cross-compiler and I have 4 different ARM
> > compilers installed in /usr? How would it know which architecture's
> > cross-compiler to use?
>
> Well, how much are you expecting to Just Work without making a real
> config?  That much does work for finding cross tools installed into
> those paths.  But if you have > 1 architecture toolchain in a
> single location buildman does fail there today.
>
> > I like the interface of just setting the CROSS_COMPILE variable,
> > since I can just set it in the environment and forget it if I want.
> > Perhaps buildman could just use it if it was set, and ignore the
> > config file (or again, a simple wrapper script could do that)?
>
> I do not want a wrapper script.  Trying to make one thing act like
> another thing leads to madness and corner cases.  That said, how hard
> would it be to have buildman see if CROSS_COMPILE is set and in turn
> force that to be used for all specified build targets?  I thought about
> making it see what the value is and then heuristic which arch to use,
> but I think that's more error prone than perhaps buildman
> --default-tool-chain (Uses passed value or CROSS_COMPILE if set in env)

We can do that - is this a boolean value? What do you mean by 'passed value'?

Regards,
Simon

[U-Boot] simple buildman usage

[Stephen Warren]

On 07/14/2015 05:37 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 14 July 2015 at 17:27, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/14/2015 05:07 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 14 July 2015 at 16:39, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>>
>>>>
>>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>>
>>>>>
>>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>>
>>>>>>
>>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>>> soon.
>>>>>>>
>>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>>> migration and DM work continue moving along.
>>>>>>>
>>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>>> deprecate
>>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>>> case, we really need to talk.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>>> tree, and run the following to build in-tree:
>>>>>>
>>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>>
>>>>>> However, with buildman, some complex config file needed to be set up
>>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>>> source tree which takes ages for me.
>>>>>>
>>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>>> require configuration and copying?
>>>>>
>>>>>
>>>>>
>>>>> For no copying, --in-tree does what you want I think.
>>>>
>>>>
>>>>
>>>> OK. Making that the default would be useful, or providing a buildman
>>>> wrapper script in the root directory that always passes this option.
>>>
>>>
>>> $ buildman seaboard
>>>
>>> will build U-Boot for seaboard. It does not copy the git tree. It puts
>>> the output in ../current, or some other directory of your choosing. I
>>> think that's pretty convenient.
>>
>>
>> I'd prefer it to go in . so I don't get clutter outside my working tree.
>
> -o .
>
>>
>>> For toolchains you can use
>>>
>>> $ buildman --fetch-arch arm
>>>
>>> to get a default one and set it up ready for use complete with config
>>> file.
>>
>>
>> I already have the toolchain I want to use installed, so I'd like a simple
>> way to use it.
>>
>>> But honestly the config file is not that hard to figure out!
>>
>>
>> Well perhaps if you understand its concepts/semantics, but I've always had
>> an extremely hard time grasping it, and at least the last time I RTFMd there
>> weren't any examples aimed at "this is how to write a config file to just
>> use this binary name in $PATH". Equally, having to edit a config file any
>> time I want to switch compilers is a bit annoying.
>
> Agreed. Perhaps annoying enough to contribute a patch?

I recall vaguely looking at the buildman source to try and work out how 
the config file worked, but failing. Most likely, I'll just save off a 
shell snippet that runs "make xxx_config && make" and use that instead.

[U-Boot] simple buildman usage

[Stephen Warren]

On 07/14/2015 05:33 PM, Tom Rini wrote:
> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>> Hey all,
>>>>>
>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>> soon.
>>>>>
>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>> migration and DM work continue moving along.
>>>>>
>>>>> Looking over the announcement for v2015.04, I see I said we'd deprecate
>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>> case, we really need to talk.
>>>>
>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>> tree, and run the following to build in-tree:
>>>>
>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>
>>>> However, with buildman, some complex config file needed to be set up
>>>> to configure the toolchain (and I could never parse the docs to work
>>>> out how to create it in a new checkout), plus it made copies of the
>>>> source tree which takes ages for me.
>>>>
>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>> require configuration and copying?
>>>
>>> For no copying, --in-tree does what you want I think.
>>
>> OK. Making that the default would be useful, or providing a buildman
>> wrapper script in the root directory that always passes this option.
>>
>>> For not
>>> configuring a toolchain, there's two ways to go about this.  One would
>>> be to do something like:
>>>
>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>> index e33e105..bba60d5 100644
>>> --- a/tools/buildman/toolchain.py
>>> +++ b/tools/buildman/toolchain.py
>>> @@ -159,7 +159,7 @@ class Toolchains:
>>>                    " to your buildman config file %s. See README for details" %
>>>                    bsettings.config_fname)
>>>
>>> -        paths = []
>>> +        paths = ['/usr', '/usr/local']
>>>           for name, value in toolchains:
>>>               if '*' in value:
>>>                   paths += glob.glob(value)
>>>
>>> And then any toolchains in /usr and /usr/local would be picked up and
>>> used.  Another option would be to add --tool-chain-path DIR and throw
>>> that into the above function.  Thoughts?
>>
>> Does that find cross-compilers? IIRC I had to add the full compiler
>> binary name into the config file, not just a /usr search directory,
>> so I don't think the above patch is enough to make it work. What if
>> I want to use a specific cross-compiler and I have 4 different ARM
>> compilers installed in /usr? How would it know which architecture's
>> cross-compiler to use?
>
> Well, how much are you expecting to Just Work without making a real
> config?

The same way MAKEALL did; by honoring CROSS_COMPILE:-)

[U-Boot] simple buildman usage

[Simon Glass]

Hi Stephen,

On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/14/2015 05:33 PM, Tom Rini wrote:
>>
>> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>>>
>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>
>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>
>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>> soon.
>>>>>>
>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>> migration and DM work continue moving along.
>>>>>>
>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>> deprecate
>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>> case, we really need to talk.
>>>>>
>>>>>
>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>> tree, and run the following to build in-tree:
>>>>>
>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>
>>>>> However, with buildman, some complex config file needed to be set up
>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>> source tree which takes ages for me.
>>>>>
>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>> require configuration and copying?
>>>>
>>>>
>>>> For no copying, --in-tree does what you want I think.
>>>
>>>
>>> OK. Making that the default would be useful, or providing a buildman
>>> wrapper script in the root directory that always passes this option.
>>>
>>>> For not
>>>> configuring a toolchain, there's two ways to go about this.  One would
>>>> be to do something like:
>>>>
>>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>>> index e33e105..bba60d5 100644
>>>> --- a/tools/buildman/toolchain.py
>>>> +++ b/tools/buildman/toolchain.py
>>>> @@ -159,7 +159,7 @@ class Toolchains:
>>>>                    " to your buildman config file %s. See README for
>>>> details" %
>>>>                    bsettings.config_fname)
>>>>
>>>> -        paths = []
>>>> +        paths = ['/usr', '/usr/local']
>>>>           for name, value in toolchains:
>>>>               if '*' in value:
>>>>                   paths += glob.glob(value)
>>>>
>>>> And then any toolchains in /usr and /usr/local would be picked up and
>>>> used.  Another option would be to add --tool-chain-path DIR and throw
>>>> that into the above function.  Thoughts?
>>>
>>>
>>> Does that find cross-compilers? IIRC I had to add the full compiler
>>> binary name into the config file, not just a /usr search directory,
>>> so I don't think the above patch is enough to make it work. What if
>>> I want to use a specific cross-compiler and I have 4 different ARM
>>> compilers installed in /usr? How would it know which architecture's
>>> cross-compiler to use?
>>
>>
>> Well, how much are you expecting to Just Work without making a real
>> config?
>
>
> The same way MAKEALL did; by honoring CROSS_COMPILE:-)

Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?

Regards,
Simon

[U-Boot] simple buildman usage

[Tom Rini]

On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
> Hi Stephen,
> 
> On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
> > On 07/14/2015 05:33 PM, Tom Rini wrote:
> >>
> >> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> >>>
> >>> On 07/14/2015 04:09 PM, Tom Rini wrote:
> >>>>
> >>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> >>>>>
> >>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
> >>>>>>
> >>>>>> Hey all,
> >>>>>>
> >>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
> >>>>>> soon.
> >>>>>>
> >>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
> >>>>>> migration and DM work continue moving along.
> >>>>>>
> >>>>>> Looking over the announcement for v2015.04, I see I said we'd
> >>>>>> deprecate
> >>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> >>>>>> right after the tag.  If buildman isn't working for you and your use
> >>>>>> case, we really need to talk.
> >>>>>
> >>>>>
> >>>>> The nice thing about MAKEALL was that I could simply grab a source
> >>>>> tree, and run the following to build in-tree:
> >>>>>
> >>>>> CROSS_COMPILE=something ./MAKEALL foo
> >>>>>
> >>>>> However, with buildman, some complex config file needed to be set up
> >>>>> to configure the toolchain (and I could never parse the docs to work
> >>>>> out how to create it in a new checkout), plus it made copies of the
> >>>>> source tree which takes ages for me.
> >>>>>
> >>>>> Is there an equivalently simple way to invoke buildman that doesn't
> >>>>> require configuration and copying?
> >>>>
> >>>>
> >>>> For no copying, --in-tree does what you want I think.
> >>>
> >>>
> >>> OK. Making that the default would be useful, or providing a buildman
> >>> wrapper script in the root directory that always passes this option.
> >>>
> >>>> For not
> >>>> configuring a toolchain, there's two ways to go about this.  One would
> >>>> be to do something like:
> >>>>
> >>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> >>>> index e33e105..bba60d5 100644
> >>>> --- a/tools/buildman/toolchain.py
> >>>> +++ b/tools/buildman/toolchain.py
> >>>> @@ -159,7 +159,7 @@ class Toolchains:
> >>>>                    " to your buildman config file %s. See README for
> >>>> details" %
> >>>>                    bsettings.config_fname)
> >>>>
> >>>> -        paths = []
> >>>> +        paths = ['/usr', '/usr/local']
> >>>>           for name, value in toolchains:
> >>>>               if '*' in value:
> >>>>                   paths += glob.glob(value)
> >>>>
> >>>> And then any toolchains in /usr and /usr/local would be picked up and
> >>>> used.  Another option would be to add --tool-chain-path DIR and throw
> >>>> that into the above function.  Thoughts?
> >>>
> >>>
> >>> Does that find cross-compilers? IIRC I had to add the full compiler
> >>> binary name into the config file, not just a /usr search directory,
> >>> so I don't think the above patch is enough to make it work. What if
> >>> I want to use a specific cross-compiler and I have 4 different ARM
> >>> compilers installed in /usr? How would it know which architecture's
> >>> cross-compiler to use?
> >>
> >>
> >> Well, how much are you expecting to Just Work without making a real
> >> config?
> >
> >
> > The same way MAKEALL did; by honoring CROSS_COMPILE:-)
> 
> Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?

And that's the problem / hard part about having buildman do something
with CROSS_COMPILE.  CROSS_COMPILE is inherently single-arch.  And while
that's fine for some use cases that's a huge problem for other use
cases.  What I have in mind is we add an option called say:
--add-tool-chain=PREFIX.  Will force PREFIX to be the toolchain used
for whatever architecture the heuristics apply it to.  This will
override anything found by the automagic checking.

This means that everyone that has automagic scripts for kernel building
can wrap in --add-tool-chain=${CROSS_COMPILE} and be done with it.  This
is slightlyd different than when I was thinking last night, but I think
more useful / less likely to surprise people.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150715/f97fe9b7/attachment.sig>

[U-Boot] simple buildman usage

[Stephen Warren]

On 07/15/2015 09:54 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/14/2015 05:33 PM, Tom Rini wrote:
>>>
>>> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>>>>
>>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>>
>>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>>
>>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>>> soon.
>>>>>>>
>>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>>> migration and DM work continue moving along.
>>>>>>>
>>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>>> deprecate
>>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>>> case, we really need to talk.
>>>>>>
>>>>>>
>>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>>> tree, and run the following to build in-tree:
>>>>>>
>>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>>
>>>>>> However, with buildman, some complex config file needed to be set up
>>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>>> source tree which takes ages for me.
>>>>>>
>>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>>> require configuration and copying?
>>>>>
>>>>>
>>>>> For no copying, --in-tree does what you want I think.
>>>>
>>>>
>>>> OK. Making that the default would be useful, or providing a buildman
>>>> wrapper script in the root directory that always passes this option.
>>>>
>>>>> For not
>>>>> configuring a toolchain, there's two ways to go about this.  One would
>>>>> be to do something like:
>>>>>
>>>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>>>> index e33e105..bba60d5 100644
>>>>> --- a/tools/buildman/toolchain.py
>>>>> +++ b/tools/buildman/toolchain.py
>>>>> @@ -159,7 +159,7 @@ class Toolchains:
>>>>>                     " to your buildman config file %s. See README for
>>>>> details" %
>>>>>                     bsettings.config_fname)
>>>>>
>>>>> -        paths = []
>>>>> +        paths = ['/usr', '/usr/local']
>>>>>            for name, value in toolchains:
>>>>>                if '*' in value:
>>>>>                    paths += glob.glob(value)
>>>>>
>>>>> And then any toolchains in /usr and /usr/local would be picked up and
>>>>> used.  Another option would be to add --tool-chain-path DIR and throw
>>>>> that into the above function.  Thoughts?
>>>>
>>>>
>>>> Does that find cross-compilers? IIRC I had to add the full compiler
>>>> binary name into the config file, not just a /usr search directory,
>>>> so I don't think the above patch is enough to make it work. What if
>>>> I want to use a specific cross-compiler and I have 4 different ARM
>>>> compilers installed in /usr? How would it know which architecture's
>>>> cross-compiler to use?
>>>
>>>
>>> Well, how much are you expecting to Just Work without making a real
>>> config?
>>
>>
>> The same way MAKEALL did; by honoring CROSS_COMPILE:-)
>
> Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?

No, I almost always only build for ARM. I just very rarely build for 
x86/sandbox, which simply requires not including the CROSS_COMPILE value 
on the command-line. For new shells, I simply cut/paste the 
command-lines from a text file I keep my shell history all saved it, so 
I find it quite easy.

[U-Boot] simple buildman usage

[Simon Glass]

Hi Stephen,

On 15 July 2015 at 10:28, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/15/2015 09:54 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>
>>> On 07/14/2015 05:33 PM, Tom Rini wrote:
>>>>
>>>>
>>>> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>>>>>
>>>>>
>>>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>>>> soon.
>>>>>>>>
>>>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>>>> migration and DM work continue moving along.
>>>>>>>>
>>>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>>>> deprecate
>>>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>>>> case, we really need to talk.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>>>> tree, and run the following to build in-tree:
>>>>>>>
>>>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>>>
>>>>>>> However, with buildman, some complex config file needed to be set up
>>>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>>>> source tree which takes ages for me.
>>>>>>>
>>>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>>>> require configuration and copying?
>>>>>>
>>>>>>
>>>>>>
>>>>>> For no copying, --in-tree does what you want I think.
>>>>>
>>>>>
>>>>>
>>>>> OK. Making that the default would be useful, or providing a buildman
>>>>> wrapper script in the root directory that always passes this option.
>>>>>
>>>>>> For not
>>>>>> configuring a toolchain, there's two ways to go about this.  One would
>>>>>> be to do something like:
>>>>>>
>>>>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>>>>> index e33e105..bba60d5 100644
>>>>>> --- a/tools/buildman/toolchain.py
>>>>>> +++ b/tools/buildman/toolchain.py
>>>>>> @@ -159,7 +159,7 @@ class Toolchains:
>>>>>>                     " to your buildman config file %s. See README for
>>>>>> details" %
>>>>>>                     bsettings.config_fname)
>>>>>>
>>>>>> -        paths = []
>>>>>> +        paths = ['/usr', '/usr/local']
>>>>>>            for name, value in toolchains:
>>>>>>                if '*' in value:
>>>>>>                    paths += glob.glob(value)
>>>>>>
>>>>>> And then any toolchains in /usr and /usr/local would be picked up and
>>>>>> used.  Another option would be to add --tool-chain-path DIR and throw
>>>>>> that into the above function.  Thoughts?
>>>>>
>>>>>
>>>>>
>>>>> Does that find cross-compilers? IIRC I had to add the full compiler
>>>>> binary name into the config file, not just a /usr search directory,
>>>>> so I don't think the above patch is enough to make it work. What if
>>>>> I want to use a specific cross-compiler and I have 4 different ARM
>>>>> compilers installed in /usr? How would it know which architecture's
>>>>> cross-compiler to use?
>>>>
>>>>
>>>>
>>>> Well, how much are you expecting to Just Work without making a real
>>>> config?
>>>
>>>
>>>
>>> The same way MAKEALL did; by honoring CROSS_COMPILE:-)
>>
>>
>> Do you give it a different CROSS_COMPILE for every arch? Isn't that a
>> pain?
>
>
> No, I almost always only build for ARM. I just very rarely build for
> x86/sandbox, which simply requires not including the CROSS_COMPILE value on
> the command-line. For new shells, I simply cut/paste the command-lines from
> a text file I keep my shell history all saved it, so I find it quite easy.

OK. Do you think Tom's idea works for you? Perhaps reply on that
thread. I'm willing to work up a patch if yes as I assume your use
case is not that unusual.

Regards,
Simon

[U-Boot] simple buildman usage

[Stephen Warren]

On 07/15/2015 10:14 AM, Tom Rini wrote:
> On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 07/14/2015 05:33 PM, Tom Rini wrote:
>>>>
>>>> On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
>>>>>
>>>>> On 07/14/2015 04:09 PM, Tom Rini wrote:
>>>>>>
>>>>>> On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
>>>>>>>
>>>>>>> On 07/14/2015 11:56 AM, Tom Rini wrote:
>>>>>>>>
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> I've pushed v2015.07 out to the repository and tarballs should exist
>>>>>>>> soon.
>>>>>>>>
>>>>>>>> This sounds a bit like a broken record, but it's true.  The Kconfig
>>>>>>>> migration and DM work continue moving along.
>>>>>>>>
>>>>>>>> Looking over the announcement for v2015.04, I see I said we'd
>>>>>>>> deprecate
>>>>>>>> MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
>>>>>>>> right after the tag.  If buildman isn't working for you and your use
>>>>>>>> case, we really need to talk.
>>>>>>>
>>>>>>>
>>>>>>> The nice thing about MAKEALL was that I could simply grab a source
>>>>>>> tree, and run the following to build in-tree:
>>>>>>>
>>>>>>> CROSS_COMPILE=something ./MAKEALL foo
>>>>>>>
>>>>>>> However, with buildman, some complex config file needed to be set up
>>>>>>> to configure the toolchain (and I could never parse the docs to work
>>>>>>> out how to create it in a new checkout), plus it made copies of the
>>>>>>> source tree which takes ages for me.
>>>>>>>
>>>>>>> Is there an equivalently simple way to invoke buildman that doesn't
>>>>>>> require configuration and copying?
>>>>>>
>>>>>>
>>>>>> For no copying, --in-tree does what you want I think.
>>>>>
>>>>>
>>>>> OK. Making that the default would be useful, or providing a buildman
>>>>> wrapper script in the root directory that always passes this option.
>>>>>
>>>>>> For not
>>>>>> configuring a toolchain, there's two ways to go about this.  One would
>>>>>> be to do something like:
>>>>>>
>>>>>> diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
>>>>>> index e33e105..bba60d5 100644
>>>>>> --- a/tools/buildman/toolchain.py
>>>>>> +++ b/tools/buildman/toolchain.py
>>>>>> @@ -159,7 +159,7 @@ class Toolchains:
>>>>>>                     " to your buildman config file %s. See README for
>>>>>> details" %
>>>>>>                     bsettings.config_fname)
>>>>>>
>>>>>> -        paths = []
>>>>>> +        paths = ['/usr', '/usr/local']
>>>>>>            for name, value in toolchains:
>>>>>>                if '*' in value:
>>>>>>                    paths += glob.glob(value)
>>>>>>
>>>>>> And then any toolchains in /usr and /usr/local would be picked up and
>>>>>> used.  Another option would be to add --tool-chain-path DIR and throw
>>>>>> that into the above function.  Thoughts?
>>>>>
>>>>>
>>>>> Does that find cross-compilers? IIRC I had to add the full compiler
>>>>> binary name into the config file, not just a /usr search directory,
>>>>> so I don't think the above patch is enough to make it work. What if
>>>>> I want to use a specific cross-compiler and I have 4 different ARM
>>>>> compilers installed in /usr? How would it know which architecture's
>>>>> cross-compiler to use?
>>>>
>>>>
>>>> Well, how much are you expecting to Just Work without making a real
>>>> config?
>>>
>>>
>>> The same way MAKEALL did; by honoring CROSS_COMPILE:-)
>>
>> Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?

(I think this is the email Simon asked me to respond to...)

> And that's the problem / hard part about having buildman do something
> with CROSS_COMPILE.  CROSS_COMPILE is inherently single-arch.

IIRC I've seen other projects use CROSS_COMPILE_ARM, CROSS_COMPILE_X86, 
etc. and blindly use those without any kind of probing/heuristics, but 
rather purely based on the architecture the tool is building for.

I'd certainly prefer something that just uses the toolchain that it's 
told to rather than trying to probe a list of them, even if I can force 
something to override the list.

 > And while
> that's fine for some use cases that's a huge problem for other use
> cases.  What I have in mind is we add an option called say:
> --add-tool-chain=PREFIX.  Will force PREFIX to be the toolchain used
> for whatever architecture the heuristics apply it to.  This will
> override anything found by the automagic checking.
>
> This means that everyone that has automagic scripts for kernel building
> can wrap in --add-tool-chain=${CROSS_COMPILE} and be done with it.  This
> is slightlyd different than when I was thinking last night, but I think
> more useful / less likely to surprise people.
>

[U-Boot] simple buildman usage

[Tom Rini]

On Wed, Jul 15, 2015 at 02:12:15PM -0600, Stephen Warren wrote:
> On 07/15/2015 10:14 AM, Tom Rini wrote:
> >On Wed, Jul 15, 2015 at 09:54:41AM -0600, Simon Glass wrote:
> >>Hi Stephen,
> >>
> >>On 15 July 2015 at 09:50, Stephen Warren <swarren@wwwdotorg.org> wrote:
> >>>On 07/14/2015 05:33 PM, Tom Rini wrote:
> >>>>
> >>>>On Tue, Jul 14, 2015 at 04:39:01PM -0600, Stephen Warren wrote:
> >>>>>
> >>>>>On 07/14/2015 04:09 PM, Tom Rini wrote:
> >>>>>>
> >>>>>>On Tue, Jul 14, 2015 at 02:11:25PM -0600, Stephen Warren wrote:
> >>>>>>>
> >>>>>>>On 07/14/2015 11:56 AM, Tom Rini wrote:
> >>>>>>>>
> >>>>>>>>Hey all,
> >>>>>>>>
> >>>>>>>>I've pushed v2015.07 out to the repository and tarballs should exist
> >>>>>>>>soon.
> >>>>>>>>
> >>>>>>>>This sounds a bit like a broken record, but it's true.  The Kconfig
> >>>>>>>>migration and DM work continue moving along.
> >>>>>>>>
> >>>>>>>>Looking over the announcement for v2015.04, I see I said we'd
> >>>>>>>>deprecate
> >>>>>>>>MAKEALL.  So I've applied http://patchwork.ozlabs.org/patch/383960/
> >>>>>>>>right after the tag.  If buildman isn't working for you and your use
> >>>>>>>>case, we really need to talk.
> >>>>>>>
> >>>>>>>
> >>>>>>>The nice thing about MAKEALL was that I could simply grab a source
> >>>>>>>tree, and run the following to build in-tree:
> >>>>>>>
> >>>>>>>CROSS_COMPILE=something ./MAKEALL foo
> >>>>>>>
> >>>>>>>However, with buildman, some complex config file needed to be set up
> >>>>>>>to configure the toolchain (and I could never parse the docs to work
> >>>>>>>out how to create it in a new checkout), plus it made copies of the
> >>>>>>>source tree which takes ages for me.
> >>>>>>>
> >>>>>>>Is there an equivalently simple way to invoke buildman that doesn't
> >>>>>>>require configuration and copying?
> >>>>>>
> >>>>>>
> >>>>>>For no copying, --in-tree does what you want I think.
> >>>>>
> >>>>>
> >>>>>OK. Making that the default would be useful, or providing a buildman
> >>>>>wrapper script in the root directory that always passes this option.
> >>>>>
> >>>>>>For not
> >>>>>>configuring a toolchain, there's two ways to go about this.  One would
> >>>>>>be to do something like:
> >>>>>>
> >>>>>>diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
> >>>>>>index e33e105..bba60d5 100644
> >>>>>>--- a/tools/buildman/toolchain.py
> >>>>>>+++ b/tools/buildman/toolchain.py
> >>>>>>@@ -159,7 +159,7 @@ class Toolchains:
> >>>>>>                    " to your buildman config file %s. See README for
> >>>>>>details" %
> >>>>>>                    bsettings.config_fname)
> >>>>>>
> >>>>>>-        paths = []
> >>>>>>+        paths = ['/usr', '/usr/local']
> >>>>>>           for name, value in toolchains:
> >>>>>>               if '*' in value:
> >>>>>>                   paths += glob.glob(value)
> >>>>>>
> >>>>>>And then any toolchains in /usr and /usr/local would be picked up and
> >>>>>>used.  Another option would be to add --tool-chain-path DIR and throw
> >>>>>>that into the above function.  Thoughts?
> >>>>>
> >>>>>
> >>>>>Does that find cross-compilers? IIRC I had to add the full compiler
> >>>>>binary name into the config file, not just a /usr search directory,
> >>>>>so I don't think the above patch is enough to make it work. What if
> >>>>>I want to use a specific cross-compiler and I have 4 different ARM
> >>>>>compilers installed in /usr? How would it know which architecture's
> >>>>>cross-compiler to use?
> >>>>
> >>>>
> >>>>Well, how much are you expecting to Just Work without making a real
> >>>>config?
> >>>
> >>>
> >>>The same way MAKEALL did; by honoring CROSS_COMPILE:-)
> >>
> >>Do you give it a different CROSS_COMPILE for every arch? Isn't that a pain?
> 
> (I think this is the email Simon asked me to respond to...)
> 
> >And that's the problem / hard part about having buildman do something
> >with CROSS_COMPILE.  CROSS_COMPILE is inherently single-arch.
> 
> IIRC I've seen other projects use CROSS_COMPILE_ARM,
> CROSS_COMPILE_X86, etc. and blindly use those without any kind of
> probing/heuristics, but rather purely based on the architecture the
> tool is building for.
> 
> I'd certainly prefer something that just uses the toolchain that
> it's told to rather than trying to probe a list of them, even if I
> can force something to override the list.

Which is what the preferences file is for[1].  But since you're trying to
avoid making one...

> > And while
> >that's fine for some use cases that's a huge problem for other use
> >cases.  What I have in mind is we add an option called say:
> >--add-tool-chain=PREFIX.  Will force PREFIX to be the toolchain used
> >for whatever architecture the heuristics apply it to.  This will
> >override anything found by the automagic checking.
> >
> >This means that everyone that has automagic scripts for kernel building
> >can wrap in --add-tool-chain=${CROSS_COMPILE} and be done with it.  This
> >is slightlyd different than when I was thinking last night, but I think
> >more useful / less likely to surprise people.

Does this do what you're asking for?

[1]: Yes, it's not quite right in all cases, which I consider something
that needs work.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150715/65583901/attachment.sig>

[U-Boot] [ANN] U-Boot v2015.07 released

[Simon Glass]

Hi Wolfgang,

On 15 July 2015 at 01:15, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom,
>
> In message <20150714175627.GJ23886@bill-the-cat> you wrote:
>>
>> I've pushed v2015.07 out to the repository and tarballs should exist
>> soon.
>
> Tarballs are both on the ACD [1] and the FTP server [2].
>
> [1] https://www.amazon.com/clouddrive/share/zgc1Jd4CgnLfkP0DypkZAvXAM8Hz3IOiHbM9edV1PB8?ref_=cd_share_link_copy
> [2] ftp://ftp.denx.de/pub/u-boot/u-boot-2015.07.tar.bz2
>
> Thanks!
>
>
> Wolfgang Denk

I don't see the normal statistics - are they coming?

Regards,
Simon

[U-Boot] [ANN] U-Boot v2015.07 released

[Wolfgang Denk]

Dear Tom,

In message <20150714175627.GJ23886@bill-the-cat> you wrote:
>
> I've pushed v2015.07 out to the repository and tarballs should exist
> soon.

Here finally the release statistics - sorry this took so long.  For
the full list please see [1].

[1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07


Processed 1563 csets from 156 developers
24 employers found
A total of 176355 lines added, 44130 removed (delta 132225)

Developers with the most changesets
Simon Glass                311 (19.9%)
Joe Hershberger            111 (7.1%)
Hans de Goede              106 (6.8%)
Tim Harvey                  77 (4.9%)
Masahiro Yamada             68 (4.4%)
Bin Meng                    56 (3.6%)
Jagannadh Teki              44 (2.8%)
Przemyslaw Marczak          43 (2.8%)
Paul Kocialkowski           42 (2.7%)
Kishon Vijay Abraham I      41 (2.6%)
...

Developers with the most changed lines
Masahiro Yamada           56181 (28.7%)
Simon Glass               22872 (11.7%)
Hans de Goede             19807 (10.1%)
Kishon Vijay Abraham I    15720 (8.0%)
Joe Hershberger           13351 (6.8%)
Prabhakar Kushwaha        6857 (3.5%)
Przemyslaw Marczak        6471 (3.3%)
Stefan Roese              3275 (1.7%)
Bin Meng                  3114 (1.6%)
Haikun Wang               3058 (1.6%)
...

Developers with the most lines removed
Andreas Bie?mann         2018 (4.6%)
Angelo Dureghello         1628 (3.7%)
Stefan Roese              1117 (2.5%)
Peter Robinson            1105 (2.5%)
Jagannadh Teki            1001 (2.3%)
Ian Campbell               354 (0.8%)
Valentin Longchamp         116 (0.3%)
Lars Poeschel               52 (0.1%)
Jagannadha Sutradharudu Teki   41 (0.1%)
Stephen Warren              15 (0.0%)
...

Developers with the most signoffs (total 302)
Tom Warren                  60 (19.9%)
Hans de Goede               55 (18.2%)
Michal Simek                19 (6.3%)
York Sun                    19 (6.3%)
Tom Rini                    10 (3.3%)
Nishanth Menon               9 (3.0%)
Rabeeh Khoury                8 (2.6%)
Andre Przywara               6 (2.0%)
Rob Herring                  5 (1.7%)
Radha Mohan Chintakuntla     5 (1.7%)
...

Developers with the most reviews (total 486)
Simon Glass                101 (20.8%)
Marek Vasut                 88 (18.1%)
Tom Rini                    80 (16.5%)
York Sun                    50 (10.3%)
?ukasz Majewski            41 (8.4%)
Bin Meng                    38 (7.8%)
Hans de Goede               15 (3.1%)
Joe Hershberger             14 (2.9%)
Jagannadha Sutradharudu Teki   13 (2.7%)
Jagannadh Teki              12 (2.5%)
...

Developers with the most test credits (total 127)
Simon Glass                 17 (13.4%)
Kevin Smith                 14 (11.0%)
Dirk Eibach                 13 (10.2%)
Thierry Reding              11 (8.7%)
Ian Campbell                11 (8.7%)
Vagrant Cascadian            9 (7.1%)
Jagannadh Teki               8 (6.3%)
Haikun Wang                  6 (4.7%)
Bin Meng                     4 (3.1%)
Joe Hershberger              3 (2.4%)
...

Developers who gave the most tested-by credits (total 127)
Stefan Roese                27 (21.3%)
Jan Kiszka                  18 (14.2%)
Fabio Estevam               11 (8.7%)
Przemyslaw Marczak          11 (8.7%)
Simon Glass                  8 (6.3%)
Haikun Wang                  8 (6.3%)
Ian Campbell                 6 (4.7%)
Jagannadh Teki               5 (3.9%)
Heiko Schocher               4 (3.1%)
Bin Meng                     3 (2.4%)
...

Developers with the most report credits (total 21)
Simon Glass                  5 (23.8%)
Joe Hershberger              2 (9.5%)
Ingrid Viitanen              2 (9.5%)
Haikun Wang                  1 (4.8%)
Bin Meng                     1 (4.8%)
Tim Harvey                   1 (4.8%)
Michal Simek                 1 (4.8%)
Pavel Machek                 1 (4.8%)
Vagrant Cascadian            1 (4.8%)
Maxin B. John                1 (4.8%)
...

Developers who gave the most report credits (total 21)
Simon Glass                  7 (33.3%)
Joe Hershberger              5 (23.8%)
Lokesh Vutla                 3 (14.3%)
Fabio Estevam                2 (9.5%)
Tom Rini                     1 (4.8%)
Jagannadha Sutradharudu Teki    1 (4.8%)
Daniel Schwierzeck           1 (4.8%)
Hans de Goede                1 (4.8%)

Top changeset contributors by employer
(Unknown)                  571 (36.5%)
Google, Inc.               312 (20.0%)
Freescale                  151 (9.7%)
National Instruments       111 (7.1%)
Red Hat                    106 (6.8%)
Texas Instruments           81 (5.2%)
DENX Software Engineering   73 (4.7%)
Samsung                     65 (4.2%)
Xilinx                      25 (1.6%)
Siemens                     14 (0.9%)
...

Top lines changed by employer
(Unknown)                 86637 (44.3%)
Google, Inc.              22901 (11.7%)
Red Hat                   19807 (10.1%)
Freescale                 19443 (9.9%)
Texas Instruments         17540 (9.0%)
National Instruments      13351 (6.8%)
Samsung                   6796 (3.5%)
DENX Software Engineering 6241 (3.2%)
Xilinx                     890 (0.5%)
Siemens                    412 (0.2%)
...

Employers with the most signoffs (total 302)
(Unknown)                   61 (20.2%)
NVidia                      60 (19.9%)
Red Hat                     55 (18.2%)
Freescale                   51 (16.9%)
Texas Instruments           22 (7.3%)
Xilinx                      20 (6.6%)
Samsung                     10 (3.3%)
Siemens                      7 (2.3%)
Google, Inc.                 5 (1.7%)
Renesas Electronics          5 (1.7%)
...

Employers with the most hackers (total 158)
(Unknown)                   81 (51.3%)
Freescale                   25 (15.8%)
Texas Instruments            9 (5.7%)
Samsung                      6 (3.8%)
DENX Software Engineering    5 (3.2%)
Linaro                       5 (3.2%)
Xilinx                       3 (1.9%)
Marvell                      3 (1.9%)
NVidia                       2 (1.3%)
Siemens                      2 (1.3%)
...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That was the thing about deserts. They had their  own  gravity.  They
sucked you into the centre.           - Terry Pratchett, _Small Gods_

[U-Boot] [ANN] U-Boot v2015.07 released

[Jagan Teki]

On 7 August 2015 at 12:33, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom,
>
> In message <20150714175627.GJ23886@bill-the-cat> you wrote:
>>
>> I've pushed v2015.07 out to the repository and tarballs should exist
>> soon.
>
> Here finally the release statistics - sorry this took so long.  For
> the full list please see [1].
>
> [1] http://www.denx.de/wiki/U-Boot/UbootStat_2015_07
>
>
> Processed 1563 csets from 156 developers
> 24 employers found
> A total of 176355 lines added, 44130 removed (delta 132225)
>
> Developers with the most changesets
> Simon Glass                311 (19.9%)
> Joe Hershberger            111 (7.1%)
> Hans de Goede              106 (6.8%)
> Tim Harvey                  77 (4.9%)
> Masahiro Yamada             68 (4.4%)
> Bin Meng                    56 (3.6%)
> Jagannadh Teki              44 (2.8%)
> Przemyslaw Marczak          43 (2.8%)
> Paul Kocialkowski           42 (2.7%)
> Kishon Vijay Abraham I      41 (2.6%)
> ...
>
> Developers with the most changed lines
> Masahiro Yamada           56181 (28.7%)
> Simon Glass               22872 (11.7%)
> Hans de Goede             19807 (10.1%)
> Kishon Vijay Abraham I    15720 (8.0%)
> Joe Hershberger           13351 (6.8%)
> Prabhakar Kushwaha        6857 (3.5%)
> Przemyslaw Marczak        6471 (3.3%)
> Stefan Roese              3275 (1.7%)
> Bin Meng                  3114 (1.6%)
> Haikun Wang               3058 (1.6%)
> ...
>
> Developers with the most lines removed
> Andreas Bie?mann         2018 (4.6%)
> Angelo Dureghello         1628 (3.7%)
> Stefan Roese              1117 (2.5%)
> Peter Robinson            1105 (2.5%)
> Jagannadh Teki            1001 (2.3%)
> Ian Campbell               354 (0.8%)
> Valentin Longchamp         116 (0.3%)
> Lars Poeschel               52 (0.1%)
> Jagannadha Sutradharudu Teki   41 (0.1%)
> Stephen Warren              15 (0.0%)
> ...
>
> Developers with the most signoffs (total 302)
> Tom Warren                  60 (19.9%)
> Hans de Goede               55 (18.2%)
> Michal Simek                19 (6.3%)
> York Sun                    19 (6.3%)
> Tom Rini                    10 (3.3%)
> Nishanth Menon               9 (3.0%)
> Rabeeh Khoury                8 (2.6%)
> Andre Przywara               6 (2.0%)
> Rob Herring                  5 (1.7%)
> Radha Mohan Chintakuntla     5 (1.7%)
> ...
>
> Developers with the most reviews (total 486)
> Simon Glass                101 (20.8%)
> Marek Vasut                 88 (18.1%)
> Tom Rini                    80 (16.5%)
> York Sun                    50 (10.3%)
> ?ukasz Majewski            41 (8.4%)
> Bin Meng                    38 (7.8%)
> Hans de Goede               15 (3.1%)
> Joe Hershberger             14 (2.9%)
> Jagannadha Sutradharudu Teki   13 (2.7%)
> Jagannadh Teki              12 (2.5%)
> ...
>
> Developers with the most test credits (total 127)
> Simon Glass                 17 (13.4%)
> Kevin Smith                 14 (11.0%)
> Dirk Eibach                 13 (10.2%)
> Thierry Reding              11 (8.7%)
> Ian Campbell                11 (8.7%)
> Vagrant Cascadian            9 (7.1%)
> Jagannadh Teki               8 (6.3%)
> Haikun Wang                  6 (4.7%)
> Bin Meng                     4 (3.1%)
> Joe Hershberger              3 (2.4%)
> ...
>
> Developers who gave the most tested-by credits (total 127)
> Stefan Roese                27 (21.3%)
> Jan Kiszka                  18 (14.2%)
> Fabio Estevam               11 (8.7%)
> Przemyslaw Marczak          11 (8.7%)
> Simon Glass                  8 (6.3%)
> Haikun Wang                  8 (6.3%)
> Ian Campbell                 6 (4.7%)
> Jagannadh Teki               5 (3.9%)
> Heiko Schocher               4 (3.1%)
> Bin Meng                     3 (2.4%)
> ...
>
> Developers with the most report credits (total 21)
> Simon Glass                  5 (23.8%)
> Joe Hershberger              2 (9.5%)
> Ingrid Viitanen              2 (9.5%)
> Haikun Wang                  1 (4.8%)
> Bin Meng                     1 (4.8%)
> Tim Harvey                   1 (4.8%)
> Michal Simek                 1 (4.8%)
> Pavel Machek                 1 (4.8%)
> Vagrant Cascadian            1 (4.8%)
> Maxin B. John                1 (4.8%)
> ...
>
> Developers who gave the most report credits (total 21)
> Simon Glass                  7 (33.3%)
> Joe Hershberger              5 (23.8%)
> Lokesh Vutla                 3 (14.3%)
> Fabio Estevam                2 (9.5%)
> Tom Rini                     1 (4.8%)
> Jagannadha Sutradharudu Teki    1 (4.8%)
> Daniel Schwierzeck           1 (4.8%)
> Hans de Goede                1 (4.8%)
>
> Top changeset contributors by employer
> (Unknown)                  571 (36.5%)
> Google, Inc.               312 (20.0%)
> Freescale                  151 (9.7%)
> National Instruments       111 (7.1%)
> Red Hat                    106 (6.8%)
> Texas Instruments           81 (5.2%)
> DENX Software Engineering   73 (4.7%)
> Samsung                     65 (4.2%)
> Xilinx                      25 (1.6%)
> Siemens                     14 (0.9%)
> ...
>
> Top lines changed by employer
> (Unknown)                 86637 (44.3%)
> Google, Inc.              22901 (11.7%)
> Red Hat                   19807 (10.1%)
> Freescale                 19443 (9.9%)
> Texas Instruments         17540 (9.0%)
> National Instruments      13351 (6.8%)
> Samsung                   6796 (3.5%)
> DENX Software Engineering 6241 (3.2%)
> Xilinx                     890 (0.5%)
> Siemens                    412 (0.2%)
> ...
>
> Employers with the most signoffs (total 302)
> (Unknown)                   61 (20.2%)
> NVidia                      60 (19.9%)
> Red Hat                     55 (18.2%)
> Freescale                   51 (16.9%)
> Texas Instruments           22 (7.3%)
> Xilinx                      20 (6.6%)
> Samsung                     10 (3.3%)
> Siemens                      7 (2.3%)
> Google, Inc.                 5 (1.7%)
> Renesas Electronics          5 (1.7%)
> ...

Any idea why would openedev missing on employer, does we need to
indicate some where
as all code was s-o-b openedev.com

>
> Employers with the most hackers (total 158)
> (Unknown)                   81 (51.3%)
> Freescale                   25 (15.8%)
> Texas Instruments            9 (5.7%)
> Samsung                      6 (3.8%)
> DENX Software Engineering    5 (3.2%)
> Linaro                       5 (3.2%)
> Xilinx                       3 (1.9%)
> Marvell                      3 (1.9%)
> NVidia                       2 (1.3%)
> Siemens                      2 (1.3%)
> ...
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> That was the thing about deserts. They had their  own  gravity.  They
> sucked you into the centre.           - Terry Pratchett, _Small Gods_
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

thanks!
-- 
Jagan | openedev.

[U-Boot] [ANN] U-Boot v2015.07 released

[Wolfgang Denk]

Dear Jagan,

In message <CAD6G_RTB0KyiYMWv5_jQ0VPzJ3P+5vYPgrYwsLUAX=gYgOfeSA@mail.gmail.com> you wrote:
>
> Any idea why would openedev missing on employer, does we need to
> indicate some where
> as all code was s-o-b openedev.com

openedev.com has no entry in the domain-map.

What should I add?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When the ax entered the forest, the trees said, "The handle is one of
us!"                                               -- Turkish proverb