[U-Boot] Pull request: u-boot-net

[U-Boot] Pull request: u-boot-net

[Joe Hershberger]

A few patches that came in during the merge window and appear harmless.

These cause no additional build warnings or errors.

Thanks,
-Joe

The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:

  Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
(2015-12-18 07:28:24 -0500)

are available in the git repository at:


  git://git.denx.de/u-boot-net.git master

for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:

  net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
(2015-12-21 20:01:57 -0600)

----------------------------------------------------------------
Bin Meng (5):
      fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
      fdt: Rewrite the logic in fdt_fixup_ethernet()
      net: e1000: Remove dead codes wrapped by #if 0
      net: e1000: Remove CONFIG_MVBC_1G
      net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused

Fabio Estevam (1):
      include: net: Simplify the usage of __always_inline

 common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
 drivers/net/e1000.c     | 77 +------------------------------------------------
 drivers/net/e1000.h     | 31 --------------------
 drivers/net/e1000_spi.c |  9 +++---
 include/net.h           |  9 +++---
 5 files changed, 42 insertions(+), 148 deletions(-)

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:

> A few patches that came in during the merge window and appear harmless.

so..

> 
> These cause no additional build warnings or errors.
> 
> Thanks,
> -Joe
> 
> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
> 
>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
> (2015-12-18 07:28:24 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
> 
>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> (2015-12-21 20:01:57 -0600)
> 
> ----------------------------------------------------------------
> Bin Meng (5):
>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>       fdt: Rewrite the logic in fdt_fixup_ethernet()

This one here pushes "iocon" just over the edge, again, with ELDK 5.6.

First off, let me say that I eagarly await the gcc that will finally let
strings of garbage collected functions also be collected and dropped.
My first very quick _hack_ here to gain a tiny bit of space back was to
remove from the common case some functions in common/fdt_support.c

I really don't know a good fix for today and as Dirk has pointed out
(and I frankly agree, and have been poked about in some other places),
we really do need to take care with our image sizes when adding all of
these neat new features.

>       net: e1000: Remove dead codes wrapped by #if 0
>       net: e1000: Remove CONFIG_MVBC_1G
>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> 
> Fabio Estevam (1):
>       include: net: Simplify the usage of __always_inline
> 
>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
>  drivers/net/e1000.c     | 77 +------------------------------------------------
>  drivers/net/e1000.h     | 31 --------------------
>  drivers/net/e1000_spi.c |  9 +++---
>  include/net.h           |  9 +++---
>  5 files changed, 42 insertions(+), 148 deletions(-)
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
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/20151223/87223ae7/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Joe Hershberger]

Hi Tom,

On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
>
>> A few patches that came in during the merge window and appear harmless.
>
> so..

Hmm... With the buildman toolchains I'm using nothing broke.

>>
>> These cause no additional build warnings or errors.
>>
>> Thanks,
>> -Joe
>>
>> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
>>
>>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
>> (2015-12-18 07:28:24 -0500)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-net.git master
>>
>> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
>>
>>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>> (2015-12-21 20:01:57 -0600)
>>
>> ----------------------------------------------------------------
>> Bin Meng (5):
>>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>
> This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
>
> First off, let me say that I eagarly await the gcc that will finally let
> strings of garbage collected functions also be collected and dropped.
> My first very quick _hack_ here to gain a tiny bit of space back was to
> remove from the common case some functions in common/fdt_support.c
>
> I really don't know a good fix for today and as Dirk has pointed out
> (and I frankly agree, and have been poked about in some other places),
> we really do need to take care with our image sizes when adding all of
> these neat new features.

That's a fine goal, but features aren't free. We can have a goal of
not bloating grossly or making easily separable functionality
disable-able by adding ifdefs, but requiring that any given
combination of ifdefs in a config never grow even a few bytes seems
unwieldy. Surely keeping any target so close to the limit is a waste
of everyone's time and energy. Why not take advantage of the enormous
numbers of ifdefs and start disabling some features to get these
targets off the ledge?

-Joe

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Mon, Dec 28, 2015 at 09:02:02PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> On Wed, Dec 23, 2015 at 9:47 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
> >
> >> A few patches that came in during the merge window and appear harmless.
> >
> > so..
> 
> Hmm... With the buildman toolchains I'm using nothing broke.

What one(s) are that?  ELDK 5.3 has failed for a while for me and ELDK
5.6 just started with this PR.

> >> These cause no additional build warnings or errors.
> >>
> >> Thanks,
> >> -Joe
> >>
> >> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
> >>
> >>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
> >> (2015-12-18 07:28:24 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://git.denx.de/u-boot-net.git master
> >>
> >> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
> >>
> >>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> >> (2015-12-21 20:01:57 -0600)
> >>
> >> ----------------------------------------------------------------
> >> Bin Meng (5):
> >>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
> >>       fdt: Rewrite the logic in fdt_fixup_ethernet()
> >
> > This one here pushes "iocon" just over the edge, again, with ELDK 5.6.
> >
> > First off, let me say that I eagarly await the gcc that will finally let
> > strings of garbage collected functions also be collected and dropped.
> > My first very quick _hack_ here to gain a tiny bit of space back was to
> > remove from the common case some functions in common/fdt_support.c
> >
> > I really don't know a good fix for today and as Dirk has pointed out
> > (and I frankly agree, and have been poked about in some other places),
> > we really do need to take care with our image sizes when adding all of
> > these neat new features.
> 
> That's a fine goal, but features aren't free. We can have a goal of
> not bloating grossly or making easily separable functionality
> disable-able by adding ifdefs, but requiring that any given

Yes, this is where I do agree and wonder if we perhaps haven't been
giving enough care here.  Especially since until another big gcc release
or two we won't have the stupid string consolidation bug fixed.  We may
need to keep that bug in mind and re-think how we structure some of the
code.

> combination of ifdefs in a config never grow even a few bytes seems
> unwieldy. Surely keeping any target so close to the limit is a waste
> of everyone's time and energy. Why not take advantage of the enormous
> numbers of ifdefs and start disabling some features to get these
> targets off the ledge?

The problem with "iocon" is that we have an active board maintainer and
I'm not immediately seeing a bunch of waste that could just be turned
off here.  Perhaps Dirk will see something or another.

> 
> -Joe

-- 
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/20151229/4ef88c1f/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:

> A few patches that came in during the merge window and appear harmless.
> 
> These cause no additional build warnings or errors.
> 
> Thanks,
> -Joe
> 
> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
> 
>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
> (2015-12-18 07:28:24 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
> 
>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> (2015-12-21 20:01:57 -0600)
> 
> ----------------------------------------------------------------
> Bin Meng (5):
>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>       net: e1000: Remove dead codes wrapped by #if 0
>       net: e1000: Remove CONFIG_MVBC_1G
>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> 
> Fabio Estevam (1):
>       include: net: Simplify the usage of __always_inline
> 
>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
>  drivers/net/e1000.c     | 77 +------------------------------------------------
>  drivers/net/e1000.h     | 31 --------------------
>  drivers/net/e1000_spi.c |  9 +++---
>  include/net.h           |  9 +++---
>  5 files changed, 42 insertions(+), 148 deletions(-)

I think at this stage in the release we need to rework this and drop the
fdt patches, or defer the whole thing until we can figure out some way
to fit iocon in with the ELDK 5.6 toolchains.  Thanks!

-- 
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/20160102/938c4073/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Bin Meng]

+Dirk

On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
>
>> A few patches that came in during the merge window and appear harmless.
>>
>> These cause no additional build warnings or errors.
>>
>> Thanks,
>> -Joe
>>
>> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
>>
>>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
>> (2015-12-18 07:28:24 -0500)
>>
>> are available in the git repository at:
>>
>>
>>   git://git.denx.de/u-boot-net.git master
>>
>> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
>>
>>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>> (2015-12-21 20:01:57 -0600)
>>
>> ----------------------------------------------------------------
>> Bin Meng (5):
>>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>>       net: e1000: Remove dead codes wrapped by #if 0
>>       net: e1000: Remove CONFIG_MVBC_1G
>>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>>
>> Fabio Estevam (1):
>>       include: net: Simplify the usage of __always_inline
>>
>>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
>>  drivers/net/e1000.c     | 77 +------------------------------------------------
>>  drivers/net/e1000.h     | 31 --------------------
>>  drivers/net/e1000_spi.c |  9 +++---
>>  include/net.h           |  9 +++---
>>  5 files changed, 42 insertions(+), 148 deletions(-)
>
> I think at this stage in the release we need to rework this and drop the
> fdt patches, or defer the whole thing until we can figure out some way
> to fit iocon in with the ELDK 5.6 toolchains.  Thanks!
>
> --

I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain.
I am downloading ELDK 5.6 toolchain to see what's going on there.
IMHO, we should increase the iocon's U-Boot size to 512K. I see from
its iocon.h file its flash size is 64MB, which has plenty of spaces to
store a bigger U-Boot. Even if we try our best to rework this fdt
patch, there is still possibility to break iocon sometime in the
future by some other random fixes or new features. This to me is a
tedious process.

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
> +Dirk
> 
> On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
> >
> >> A few patches that came in during the merge window and appear harmless.
> >>
> >> These cause no additional build warnings or errors.
> >>
> >> Thanks,
> >> -Joe
> >>
> >> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
> >>
> >>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
> >> (2015-12-18 07:28:24 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://git.denx.de/u-boot-net.git master
> >>
> >> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
> >>
> >>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> >> (2015-12-21 20:01:57 -0600)
> >>
> >> ----------------------------------------------------------------
> >> Bin Meng (5):
> >>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
> >>       fdt: Rewrite the logic in fdt_fixup_ethernet()
> >>       net: e1000: Remove dead codes wrapped by #if 0
> >>       net: e1000: Remove CONFIG_MVBC_1G
> >>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
> >>
> >> Fabio Estevam (1):
> >>       include: net: Simplify the usage of __always_inline
> >>
> >>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
> >>  drivers/net/e1000.c     | 77 +------------------------------------------------
> >>  drivers/net/e1000.h     | 31 --------------------
> >>  drivers/net/e1000_spi.c |  9 +++---
> >>  include/net.h           |  9 +++---
> >>  5 files changed, 42 insertions(+), 148 deletions(-)
> >
> > I think at this stage in the release we need to rework this and drop the
> > fdt patches, or defer the whole thing until we can figure out some way
> > to fit iocon in with the ELDK 5.6 toolchains.  Thanks!
> 
> I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain.
> I am downloading ELDK 5.6 toolchain to see what's going on there.
> IMHO, we should increase the iocon's U-Boot size to 512K. I see from
> its iocon.h file its flash size is 64MB, which has plenty of spaces to
> store a bigger U-Boot. Even if we try our best to rework this fdt
> patch, there is still possibility to break iocon sometime in the
> future by some other random fixes or new features. This to me is a
> tedious process.

I don't know why this is so hard to reproduce, I also see it with the
debian/unstable gcc 5.x toolchain I do beleive.

-- 
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/20160103/a3875c20/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Bin Meng]

+Simon,

Hi Tom,

On Mon, Jan 4, 2016 at 11:46 AM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
>> +Dirk
>>
>> On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini <trini@konsulko.com> wrote:
>> > On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
>> >
>> >> A few patches that came in during the merge window and appear harmless.
>> >>
>> >> These cause no additional build warnings or errors.
>> >>
>> >> Thanks,
>> >> -Joe
>> >>
>> >> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
>> >>
>> >>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
>> >> (2015-12-18 07:28:24 -0500)
>> >>
>> >> are available in the git repository at:
>> >>
>> >>
>> >>   git://git.denx.de/u-boot-net.git master
>> >>
>> >> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
>> >>
>> >>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>> >> (2015-12-21 20:01:57 -0600)
>> >>
>> >> ----------------------------------------------------------------
>> >> Bin Meng (5):
>> >>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>> >>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>> >>       net: e1000: Remove dead codes wrapped by #if 0
>> >>       net: e1000: Remove CONFIG_MVBC_1G
>> >>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>> >>
>> >> Fabio Estevam (1):
>> >>       include: net: Simplify the usage of __always_inline
>> >>
>> >>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
>> >>  drivers/net/e1000.c     | 77 +------------------------------------------------
>> >>  drivers/net/e1000.h     | 31 --------------------
>> >>  drivers/net/e1000_spi.c |  9 +++---
>> >>  include/net.h           |  9 +++---
>> >>  5 files changed, 42 insertions(+), 148 deletions(-)
>> >
>> > I think at this stage in the release we need to rework this and drop the
>> > fdt patches, or defer the whole thing until we can figure out some way
>> > to fit iocon in with the ELDK 5.6 toolchains.  Thanks!
>>
>> I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain.
>> I am downloading ELDK 5.6 toolchain to see what's going on there.
>> IMHO, we should increase the iocon's U-Boot size to 512K. I see from
>> its iocon.h file its flash size is 64MB, which has plenty of spaces to
>> store a bigger U-Boot. Even if we try our best to rework this fdt
>> patch, there is still possibility to break iocon sometime in the
>> future by some other random fixes or new features. This to me is a
>> tedious process.
>
> I don't know why this is so hard to reproduce, I also see it with the
> debian/unstable gcc 5.x toolchain I do beleive.
>

Still downloading ELDK toolchains so cannot comment ELDK compiler
behavior :) One question, what's our recommended toolchains for
U-Boot? I have been using kernel.org toolchains as mentioned in the
buildman doc and some other ones mentioned in the moveconfig doc.

The simple fix is to change change iocon to a more larger size since
it has a 64MB flash. Dirk, can you please comment?

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Bin Meng]

On Mon, Jan 4, 2016 at 11:56 AM, Bin Meng <bmeng.cn@gmail.com> wrote:
> +Simon,
>
> Hi Tom,
>
> On Mon, Jan 4, 2016 at 11:46 AM, Tom Rini <trini@konsulko.com> wrote:
>> On Mon, Jan 04, 2016 at 10:35:39AM +0800, Bin Meng wrote:
>>> +Dirk
>>>
>>> On Sun, Jan 3, 2016 at 1:09 AM, Tom Rini <trini@konsulko.com> wrote:
>>> > On Tue, Dec 22, 2015 at 11:58:01AM -0600, Joe Hershberger wrote:
>>> >
>>> >> A few patches that came in during the merge window and appear harmless.
>>> >>
>>> >> These cause no additional build warnings or errors.
>>> >>
>>> >> Thanks,
>>> >> -Joe
>>> >>
>>> >> The following changes since commit 4832e17787acb29734d895751bc7a594908aecc6:
>>> >>
>>> >>   Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
>>> >> (2015-12-18 07:28:24 -0500)
>>> >>
>>> >> are available in the git repository at:
>>> >>
>>> >>
>>> >>   git://git.denx.de/u-boot-net.git master
>>> >>
>>> >> for you to fetch changes up to 140bc33e05382545b762ef51d6fc31dd5b6ec82c:
>>> >>
>>> >>   net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>>> >> (2015-12-21 20:01:57 -0600)
>>> >>
>>> >> ----------------------------------------------------------------
>>> >> Bin Meng (5):
>>> >>       fdt: Deprecate "usbethaddr" usage in fdt_fixup_ethernet()
>>> >>       fdt: Rewrite the logic in fdt_fixup_ethernet()
>>> >>       net: e1000: Remove dead codes wrapped by #if 0
>>> >>       net: e1000: Remove CONFIG_MVBC_1G
>>> >>       net: e1000: Mark _disable_wr() and _write_status() as __maybe_unused
>>> >>
>>> >> Fabio Estevam (1):
>>> >>       include: net: Simplify the usage of __always_inline
>>> >>
>>> >>  common/fdt_support.c    | 64 ++++++++++++++++++++--------------------
>>> >>  drivers/net/e1000.c     | 77 +------------------------------------------------
>>> >>  drivers/net/e1000.h     | 31 --------------------
>>> >>  drivers/net/e1000_spi.c |  9 +++---
>>> >>  include/net.h           |  9 +++---
>>> >>  5 files changed, 42 insertions(+), 148 deletions(-)
>>> >
>>> > I think at this stage in the release we need to rework this and drop the
>>> > fdt patches, or defer the whole thing until we can figure out some way
>>> > to fit iocon in with the ELDK 5.6 toolchains.  Thanks!
>>>
>>> I cannot reproduce this with the kernel.org powerpc gcc 4.9 toolchain.
>>> I am downloading ELDK 5.6 toolchain to see what's going on there.
>>> IMHO, we should increase the iocon's U-Boot size to 512K. I see from
>>> its iocon.h file its flash size is 64MB, which has plenty of spaces to
>>> store a bigger U-Boot. Even if we try our best to rework this fdt
>>> patch, there is still possibility to break iocon sometime in the
>>> future by some other random fixes or new features. This to me is a
>>> tedious process.
>>
>> I don't know why this is so hard to reproduce, I also see it with the
>> debian/unstable gcc 5.x toolchain I do beleive.
>>
>
> Still downloading ELDK toolchains so cannot comment ELDK compiler
> behavior :) One question, what's our recommended toolchains for
> U-Boot? I have been using kernel.org toolchains as mentioned in the
> buildman doc and some other ones mentioned in the moveconfig doc.
>
> The simple fix is to change change iocon to a more larger size since
> it has a 64MB flash. Dirk, can you please comment?
>

I am having a hard time installing ELDK 5.6 with
eldk-5.6-powerpc-4xx.iso on a CentOS machine.

Firstly, I read the help by:

$ ./install.sh -h

Usage: install.sh [-D] [-d <dir>] [-a <arch>] [-s <sdk_img> ] [-r
<rfs_img> ] [<target>]
install.sh -l [<target>]
install.sh -h
-D: Dry-run: display commands, but don't actually execute them.
-a: SDK host architecture.
    Chose one of 'i686' or 'x86_64".
Defaults to "i686".
-d: Destination directory.
Defaults to "/opt/eldk-5.6"
-h: Help: print this message.
-l: List available SDK and RFS images
-s: Select SDK image.
    Chose one of 'toolchain', 'toolchain-qte', 'toolchain-qte-xenomai',
    or '-' for none.
Defaults to "toolchain".
-r: Select list of target RFS images.
    Chose one or more of 'minimal', 'minimal-mtdutils', 'minimal-dev',
    'minimal-xenomai', 'base', 'basic', 'clutter', 'lsb',
    'lsb-dev', 'lsb-sdk', 'sato', 'sato-dev', 'sato-sdk', 'qte-sdk',
    'qte-xenomai-sdk', 'x11', or '-' for none.
Defaults to all.

<target>  target architecture, defaults to "armv7a-hf"

Then I did:

$ ./install.sh -d /share/toolchain/eldk-5.6 -r - -a x86_64 powerpc-4xx
Error: SDK image "gmae" is not available
Available SDK images for target 'powerpc-4xx':
        <none>

Then I did:

$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a
x86_64 powerpc-4xx
Error: SDK image "toolchain" is not available
Available SDK images for target 'powerpc-4xx':
        <none>

Nothing helpful was shown on the console until I figured it out I
should pass '-a i686' :(

$ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686
powerpc-4xx
*** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh
    into /share/toolchain/eldk-5.6/powerpc-4xx
tar: ./sysroots: Cannot mkdir: Read-only file system
tar: ./sysroots/ppc440e-linux: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/boot: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/bin: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/bin/.debug: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/lib: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/lib/.debug: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/lib/security: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/lib/security/.debug: Cannot mkdir: No
such file or directory
tar: ./sysroots/ppc440e-linux/lib/security/pam_filter: Cannot mkdir:
No such file or directory
tar: ./sysroots/ppc440e-linux/lib/security/pam_filter/.debug: Cannot
mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/etc: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/etc/pam.d: Cannot mkdir: No such file or directory
tar: ./sysroots/ppc440e-linux/etc/security: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/etc/security/namespace.d: Cannot mkdir:
No such file or directory
tar: ./sysroots/ppc440e-linux/etc/security/limits.d: Cannot mkdir: No
such file or directory
tar: ./sysroots/ppc440e-linux/etc/default: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/etc/default/volatiles: Cannot mkdir: No
such file or directory
tar: ./sysroots/ppc440e-linux/etc/terminfo: Cannot mkdir: No such file
or directory
tar: ./sysroots/ppc440e-linux/etc/terminfo/v: Cannot mkdir: No such
file or directory
tar: ./sysroots/ppc440e-linux/etc/terminfo/s: Cannot mkdir: No such
file or directory
<......>

Lots of 'Cannot mkdir: No such file or directory' message are shown on
the console. I am pretty sure I have RW rights on the
/share/toolchain/eldk-5.6 directory. Anything I am missing here?

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote:
[snip]
> $ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686
> powerpc-4xx
> *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh
>     into /share/toolchain/eldk-5.6/powerpc-4xx
> tar: ./sysroots: Cannot mkdir: Read-only file system
[snip]
> Lots of 'Cannot mkdir: No such file or directory' message are shown on
> the console. I am pretty sure I have RW rights on the
> /share/toolchain/eldk-5.6 directory. Anything I am missing here?

Well, please confirm that you can write to /sysroots/ :)  IIRC the
installer doesn't invoke sudo by itself, btw..

-- 
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/20160104/011fd89e/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Bin Meng]

Hi Tom,

On Mon, Jan 4, 2016 at 10:24 PM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote:
> [snip]
>> $ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686
>> powerpc-4xx
>> *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh
>>     into /share/toolchain/eldk-5.6/powerpc-4xx
>> tar: ./sysroots: Cannot mkdir: Read-only file system
> [snip]
>> Lots of 'Cannot mkdir: No such file or directory' message are shown on
>> the console. I am pretty sure I have RW rights on the
>> /share/toolchain/eldk-5.6 directory. Anything I am missing here?
>
> Well, please confirm that you can write to /sysroots/ :)  IIRC the
> installer doesn't invoke sudo by itself, btw..

The install.sh prompts ./sysroots/, not /sysroots/. ./sysroots/ should
point to the installation root where I definitely have the write
permission.

Today I switched to another machine with a Ubuntu 12.04, and with the
same iso and command I installed ELDK successfully without any error
message like "Cannot mkdir: Read-only file system". But when I used
the ELDK toolchain to build U-Boot iocon, I got:

/buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd
  -m32 -melf32ppclinux -g -Ttext 0x40000 -o
examples/standalone/hello_world -e hello_world
examples/standalone/hello_world.o examples/standalone/libstubs.o -L .
-lgcc
/buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd:
cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
make[1]: *** [examples/standalone] Error 2
make: *** [examples] Error 2

It did not help whether I just source
"environment-setup-ppc440e-linux" in the ELDK installation tree, or
just simply "export CROSS_COMPILE=path/to/ELDK/toolchain" before
building U-Boot.

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Tue, Jan 05, 2016 at 12:08:24PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Mon, Jan 4, 2016 at 10:24 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Mon, Jan 04, 2016 at 04:31:05PM +0800, Bin Meng wrote:
> > [snip]
> >> $ ./install.sh -d /share/toolchain/eldk-5.6 -s toolchain -r - -a i686
> >> powerpc-4xx
> >> *** Installing ./targets/powerpc-4xx/eldk-eglibc-i686-powerpc-toolchain-5.6.sh
> >>     into /share/toolchain/eldk-5.6/powerpc-4xx
> >> tar: ./sysroots: Cannot mkdir: Read-only file system
> > [snip]
> >> Lots of 'Cannot mkdir: No such file or directory' message are shown on
> >> the console. I am pretty sure I have RW rights on the
> >> /share/toolchain/eldk-5.6 directory. Anything I am missing here?
> >
> > Well, please confirm that you can write to /sysroots/ :)  IIRC the
> > installer doesn't invoke sudo by itself, btw..
> 
> The install.sh prompts ./sysroots/, not /sysroots/. ./sysroots/ should
> point to the installation root where I definitely have the write
> permission.
> 
> Today I switched to another machine with a Ubuntu 12.04, and with the
> same iso and command I installed ELDK successfully without any error
> message like "Cannot mkdir: Read-only file system". But when I used
> the ELDK toolchain to build U-Boot iocon, I got:
> 
> /buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd
>   -m32 -melf32ppclinux -g -Ttext 0x40000 -o
> examples/standalone/hello_world -e hello_world
> examples/standalone/hello_world.o examples/standalone/libstubs.o -L .
> -lgcc
> /buildarea1/bmeng/eldk-5.6/powerpc-4xx/sysroots/i686-eldk-linux/usr/bin/powerpc-linux/powerpc-linux-ld.bfd:
> cannot find -lgcc
> make[2]: *** [examples/standalone/hello_world] Error 1
> make[1]: *** [examples/standalone] Error 2
> make: *** [examples] Error 2
> 
> It did not help whether I just source
> "environment-setup-ppc440e-linux" in the ELDK installation tree, or
> just simply "export CROSS_COMPILE=path/to/ELDK/toolchain" before
> building U-Boot.

I've never had a problem installing and using
eldk-eglibc-i686-powerpc-toolchain-5.6.sh (or 5.5 and so on).

-- 
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/20160105/4584f746/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Dirk Eibach]

Hi Bin,

> ...
> The simple fix is to change change iocon to a more larger size since
> it has a 64MB flash. Dirk, can you please comment?

The problem is the flash partition layout, coming from a time where
u-boot was an order of magnitude smaller :)

Updating partition layout in tens of thousands of devices in the field
is not an option for us.

Cheers
Dirk

[U-Boot] Pull request: u-boot-net

[Bin Meng]

Hi Dirk,

On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> Hi Bin,
>
>> ...
>> The simple fix is to change change iocon to a more larger size since
>> it has a 64MB flash. Dirk, can you please comment?
>
> The problem is the flash partition layout, coming from a time where
> u-boot was an order of magnitude smaller :)
>

I guess so.

> Updating partition layout in tens of thousands of devices in the field
> is not an option for us.
>

I suspect 256KB won't fit anyway, if trying to make use of these new
U-Boot features,eg: using driver model adds some more footprints too.
So in your deployment, you just upgrade those devices in the field to
latest U-Boot (new version) but not changing partition layout, for fix
only?

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> Hi Dirk,
> 
> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> > Hi Bin,
> >
> >> ...
> >> The simple fix is to change change iocon to a more larger size since
> >> it has a 64MB flash. Dirk, can you please comment?
> >
> > The problem is the flash partition layout, coming from a time where
> > u-boot was an order of magnitude smaller :)
> >
> 
> I guess so.
> 
> > Updating partition layout in tens of thousands of devices in the field
> > is not an option for us.
> >
> 
> I suspect 256KB won't fit anyway, if trying to make use of these new
> U-Boot features,eg: using driver model adds some more footprints too.
> So in your deployment, you just upgrade those devices in the field to
> latest U-Boot (new version) but not changing partition layout, for fix
> only?

I'm not convinced that we shouldn't be able to be useful in 256KB.
Sure, a kitchen-sink EVM + config will be large but iocon is a defined
production type config.  If we can't make this work, I'm going to be
worried.  I've already gotten some aside pokes about making U-Boot
shrink down when you turn stuff off.

I want to cycle back to saying that we need to look at ways to
work-around the gcc issue that's keeping a bunch of unused strings in
the resulting binary.

-- 
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/20160104/9f44be68/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Bin Meng]

Hi Tom,

On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
>> Hi Dirk,
>>
>> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
>> > Hi Bin,
>> >
>> >> ...
>> >> The simple fix is to change change iocon to a more larger size since
>> >> it has a 64MB flash. Dirk, can you please comment?
>> >
>> > The problem is the flash partition layout, coming from a time where
>> > u-boot was an order of magnitude smaller :)
>> >
>>
>> I guess so.
>>
>> > Updating partition layout in tens of thousands of devices in the field
>> > is not an option for us.
>> >
>>
>> I suspect 256KB won't fit anyway, if trying to make use of these new
>> U-Boot features,eg: using driver model adds some more footprints too.
>> So in your deployment, you just upgrade those devices in the field to
>> latest U-Boot (new version) but not changing partition layout, for fix
>> only?
>
> I'm not convinced that we shouldn't be able to be useful in 256KB.
> Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> production type config.  If we can't make this work, I'm going to be
> worried.  I've already gotten some aside pokes about making U-Boot
> shrink down when you turn stuff off.
>
> I want to cycle back to saying that we need to look at ways to
> work-around the gcc issue that's keeping a bunch of unused strings in
> the resulting binary.
>

So, what's our best way to do with this PR? I am worried that since
this iocon board is already at an edge, any ramdom bug fix (to common
codes) in the future could be the next victim.

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
> Hi Tom,
> 
> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> >> Hi Dirk,
> >>
> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> >> > Hi Bin,
> >> >
> >> >> ...
> >> >> The simple fix is to change change iocon to a more larger size since
> >> >> it has a 64MB flash. Dirk, can you please comment?
> >> >
> >> > The problem is the flash partition layout, coming from a time where
> >> > u-boot was an order of magnitude smaller :)
> >> >
> >>
> >> I guess so.
> >>
> >> > Updating partition layout in tens of thousands of devices in the field
> >> > is not an option for us.
> >> >
> >>
> >> I suspect 256KB won't fit anyway, if trying to make use of these new
> >> U-Boot features,eg: using driver model adds some more footprints too.
> >> So in your deployment, you just upgrade those devices in the field to
> >> latest U-Boot (new version) but not changing partition layout, for fix
> >> only?
> >
> > I'm not convinced that we shouldn't be able to be useful in 256KB.
> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> > production type config.  If we can't make this work, I'm going to be
> > worried.  I've already gotten some aside pokes about making U-Boot
> > shrink down when you turn stuff off.
> >
> > I want to cycle back to saying that we need to look at ways to
> > work-around the gcc issue that's keeping a bunch of unused strings in
> > the resulting binary.
> 
> So, what's our best way to do with this PR? I am worried that since
> this iocon board is already at an edge, any ramdom bug fix (to common
> codes) in the future could be the next victim.

For this PR, I think we need to push the fdt patch in question out and
for the next release look at splitting up common/fdt_support.c into
logical chunks.

-- 
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/20160105/362a3b49/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Bin Meng]

On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
>> Hi Tom,
>>
>> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
>> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
>> >> Hi Dirk,
>> >>
>> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
>> >> > Hi Bin,
>> >> >
>> >> >> ...
>> >> >> The simple fix is to change change iocon to a more larger size since
>> >> >> it has a 64MB flash. Dirk, can you please comment?
>> >> >
>> >> > The problem is the flash partition layout, coming from a time where
>> >> > u-boot was an order of magnitude smaller :)
>> >> >
>> >>
>> >> I guess so.
>> >>
>> >> > Updating partition layout in tens of thousands of devices in the field
>> >> > is not an option for us.
>> >> >
>> >>
>> >> I suspect 256KB won't fit anyway, if trying to make use of these new
>> >> U-Boot features,eg: using driver model adds some more footprints too.
>> >> So in your deployment, you just upgrade those devices in the field to
>> >> latest U-Boot (new version) but not changing partition layout, for fix
>> >> only?
>> >
>> > I'm not convinced that we shouldn't be able to be useful in 256KB.
>> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
>> > production type config.  If we can't make this work, I'm going to be
>> > worried.  I've already gotten some aside pokes about making U-Boot
>> > shrink down when you turn stuff off.
>> >
>> > I want to cycle back to saying that we need to look at ways to
>> > work-around the gcc issue that's keeping a bunch of unused strings in
>> > the resulting binary.
>>
>> So, what's our best way to do with this PR? I am worried that since
>> this iocon board is already at an edge, any ramdom bug fix (to common
>> codes) in the future could be the next victim.
>
> For this PR, I think we need to push the fdt patch in question out and
> for the next release look at splitting up common/fdt_support.c into
> logical chunks.
>

Do anyone volunteer to do this "splitting up common/fdt_support.c into
logical chunks"? I still cannot make ELDK work in my env thus cannot
make any further investigation :(

Regards,
Bin

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
> >> Hi Tom,
> >>
> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> >> >> Hi Dirk,
> >> >>
> >> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> >> >> > Hi Bin,
> >> >> >
> >> >> >> ...
> >> >> >> The simple fix is to change change iocon to a more larger size since
> >> >> >> it has a 64MB flash. Dirk, can you please comment?
> >> >> >
> >> >> > The problem is the flash partition layout, coming from a time where
> >> >> > u-boot was an order of magnitude smaller :)
> >> >> >
> >> >>
> >> >> I guess so.
> >> >>
> >> >> > Updating partition layout in tens of thousands of devices in the field
> >> >> > is not an option for us.
> >> >> >
> >> >>
> >> >> I suspect 256KB won't fit anyway, if trying to make use of these new
> >> >> U-Boot features,eg: using driver model adds some more footprints too.
> >> >> So in your deployment, you just upgrade those devices in the field to
> >> >> latest U-Boot (new version) but not changing partition layout, for fix
> >> >> only?
> >> >
> >> > I'm not convinced that we shouldn't be able to be useful in 256KB.
> >> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> >> > production type config.  If we can't make this work, I'm going to be
> >> > worried.  I've already gotten some aside pokes about making U-Boot
> >> > shrink down when you turn stuff off.
> >> >
> >> > I want to cycle back to saying that we need to look at ways to
> >> > work-around the gcc issue that's keeping a bunch of unused strings in
> >> > the resulting binary.
> >>
> >> So, what's our best way to do with this PR? I am worried that since
> >> this iocon board is already at an edge, any ramdom bug fix (to common
> >> codes) in the future could be the next victim.
> >
> > For this PR, I think we need to push the fdt patch in question out and
> > for the next release look at splitting up common/fdt_support.c into
> > logical chunks.
> >
> 
> Do anyone volunteer to do this "splitting up common/fdt_support.c into
> logical chunks"? I still cannot make ELDK work in my env thus cannot
> make any further investigation :(

I'll put it on my TODO list.  I'll leave ELDK support up to the denx
folks.

-- 
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/20160107/8ddd4078/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Joe Hershberger]

Hi Tom,

On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini <trini@konsulko.com> wrote:
> On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
>> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
>> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
>> >> Hi Tom,
>> >>
>> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
>> >> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
>> >> >> Hi Dirk,
>> >> >>
>> >> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
>> >> >> > Hi Bin,
>> >> >> >
>> >> >> >> ...
>> >> >> >> The simple fix is to change change iocon to a more larger size since
>> >> >> >> it has a 64MB flash. Dirk, can you please comment?
>> >> >> >
>> >> >> > The problem is the flash partition layout, coming from a time where
>> >> >> > u-boot was an order of magnitude smaller :)
>> >> >> >
>> >> >>
>> >> >> I guess so.
>> >> >>
>> >> >> > Updating partition layout in tens of thousands of devices in the field
>> >> >> > is not an option for us.
>> >> >> >
>> >> >>
>> >> >> I suspect 256KB won't fit anyway, if trying to make use of these new
>> >> >> U-Boot features,eg: using driver model adds some more footprints too.
>> >> >> So in your deployment, you just upgrade those devices in the field to
>> >> >> latest U-Boot (new version) but not changing partition layout, for fix
>> >> >> only?
>> >> >
>> >> > I'm not convinced that we shouldn't be able to be useful in 256KB.
>> >> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
>> >> > production type config.  If we can't make this work, I'm going to be
>> >> > worried.  I've already gotten some aside pokes about making U-Boot
>> >> > shrink down when you turn stuff off.
>> >> >
>> >> > I want to cycle back to saying that we need to look at ways to
>> >> > work-around the gcc issue that's keeping a bunch of unused strings in
>> >> > the resulting binary.
>> >>
>> >> So, what's our best way to do with this PR? I am worried that since
>> >> this iocon board is already at an edge, any ramdom bug fix (to common
>> >> codes) in the future could be the next victim.
>> >
>> > For this PR, I think we need to push the fdt patch in question out and
>> > for the next release look at splitting up common/fdt_support.c into
>> > logical chunks.
>> >
>>
>> Do anyone volunteer to do this "splitting up common/fdt_support.c into
>> logical chunks"? I still cannot make ELDK work in my env thus cannot
>> make any further investigation :(
>
> I'll put it on my TODO list.  I'll leave ELDK support up to the denx
> folks.

Maybe Bin can make a patch to disable Ethernet on iocon and apply
before the fdt patch? Or would we rather wait on this until you rework
the fdt_support? Or just rebase this pr and apply as is?

Thanks,
-Joe

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
> >> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
> >> >> Hi Tom,
> >> >>
> >> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >> >> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> >> >> >> Hi Dirk,
> >> >> >>
> >> >> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> >> >> >> > Hi Bin,
> >> >> >> >
> >> >> >> >> ...
> >> >> >> >> The simple fix is to change change iocon to a more larger size since
> >> >> >> >> it has a 64MB flash. Dirk, can you please comment?
> >> >> >> >
> >> >> >> > The problem is the flash partition layout, coming from a time where
> >> >> >> > u-boot was an order of magnitude smaller :)
> >> >> >> >
> >> >> >>
> >> >> >> I guess so.
> >> >> >>
> >> >> >> > Updating partition layout in tens of thousands of devices in the field
> >> >> >> > is not an option for us.
> >> >> >> >
> >> >> >>
> >> >> >> I suspect 256KB won't fit anyway, if trying to make use of these new
> >> >> >> U-Boot features,eg: using driver model adds some more footprints too.
> >> >> >> So in your deployment, you just upgrade those devices in the field to
> >> >> >> latest U-Boot (new version) but not changing partition layout, for fix
> >> >> >> only?
> >> >> >
> >> >> > I'm not convinced that we shouldn't be able to be useful in 256KB.
> >> >> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> >> >> > production type config.  If we can't make this work, I'm going to be
> >> >> > worried.  I've already gotten some aside pokes about making U-Boot
> >> >> > shrink down when you turn stuff off.
> >> >> >
> >> >> > I want to cycle back to saying that we need to look at ways to
> >> >> > work-around the gcc issue that's keeping a bunch of unused strings in
> >> >> > the resulting binary.
> >> >>
> >> >> So, what's our best way to do with this PR? I am worried that since
> >> >> this iocon board is already at an edge, any ramdom bug fix (to common
> >> >> codes) in the future could be the next victim.
> >> >
> >> > For this PR, I think we need to push the fdt patch in question out and
> >> > for the next release look at splitting up common/fdt_support.c into
> >> > logical chunks.
> >> >
> >>
> >> Do anyone volunteer to do this "splitting up common/fdt_support.c into
> >> logical chunks"? I still cannot make ELDK work in my env thus cannot
> >> make any further investigation :(
> >
> > I'll put it on my TODO list.  I'll leave ELDK support up to the denx
> > folks.
> 
> Maybe Bin can make a patch to disable Ethernet on iocon and apply
> before the fdt patch? Or would we rather wait on this until you rework
> the fdt_support? Or just rebase this pr and apply as is?

So, ELDK 5.3 requires a lot of lifting to get the size down to linking
(and in fact fails locally either way).  I did a bunch of easy non-FDT
trimming now, let me see if that gets the -net PR linking still and work
from there.

-- 
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/20160113/c0b2aa00/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
> >> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
> >> >> Hi Tom,
> >> >>
> >> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >> >> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> >> >> >> Hi Dirk,
> >> >> >>
> >> >> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> >> >> >> > Hi Bin,
> >> >> >> >
> >> >> >> >> ...
> >> >> >> >> The simple fix is to change change iocon to a more larger size since
> >> >> >> >> it has a 64MB flash. Dirk, can you please comment?
> >> >> >> >
> >> >> >> > The problem is the flash partition layout, coming from a time where
> >> >> >> > u-boot was an order of magnitude smaller :)
> >> >> >> >
> >> >> >>
> >> >> >> I guess so.
> >> >> >>
> >> >> >> > Updating partition layout in tens of thousands of devices in the field
> >> >> >> > is not an option for us.
> >> >> >> >
> >> >> >>
> >> >> >> I suspect 256KB won't fit anyway, if trying to make use of these new
> >> >> >> U-Boot features,eg: using driver model adds some more footprints too.
> >> >> >> So in your deployment, you just upgrade those devices in the field to
> >> >> >> latest U-Boot (new version) but not changing partition layout, for fix
> >> >> >> only?
> >> >> >
> >> >> > I'm not convinced that we shouldn't be able to be useful in 256KB.
> >> >> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> >> >> > production type config.  If we can't make this work, I'm going to be
> >> >> > worried.  I've already gotten some aside pokes about making U-Boot
> >> >> > shrink down when you turn stuff off.
> >> >> >
> >> >> > I want to cycle back to saying that we need to look at ways to
> >> >> > work-around the gcc issue that's keeping a bunch of unused strings in
> >> >> > the resulting binary.
> >> >>
> >> >> So, what's our best way to do with this PR? I am worried that since
> >> >> this iocon board is already at an edge, any ramdom bug fix (to common
> >> >> codes) in the future could be the next victim.
> >> >
> >> > For this PR, I think we need to push the fdt patch in question out and
> >> > for the next release look at splitting up common/fdt_support.c into
> >> > logical chunks.
> >> >
> >>
> >> Do anyone volunteer to do this "splitting up common/fdt_support.c into
> >> logical chunks"? I still cannot make ELDK work in my env thus cannot
> >> make any further investigation :(
> >
> > I'll put it on my TODO list.  I'll leave ELDK support up to the denx
> > folks.
> 
> Maybe Bin can make a patch to disable Ethernet on iocon and apply
> before the fdt patch? Or would we rather wait on this until you rework
> the fdt_support? Or just rebase this pr and apply as is?

So, just the hush.c patch is enough now, I'll take that and the current
PR.  I'll also post as patches some of what I've done locally.

-- 
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/20160113/73d2e06f/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Wed, Jan 13, 2016 at 02:58:41PM -0600, Joe Hershberger wrote:
> Hi Tom,
> 
> On Thu, Jan 7, 2016 at 10:29 AM, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, Jan 07, 2016 at 10:49:51AM +0800, Bin Meng wrote:
> >> On Tue, Jan 5, 2016 at 9:18 PM, Tom Rini <trini@konsulko.com> wrote:
> >> > On Tue, Jan 05, 2016 at 12:18:35PM +0800, Bin Meng wrote:
> >> >> Hi Tom,
> >> >>
> >> >> On Mon, Jan 4, 2016 at 10:22 PM, Tom Rini <trini@konsulko.com> wrote:
> >> >> > On Mon, Jan 04, 2016 at 09:48:08PM +0800, Bin Meng wrote:
> >> >> >> Hi Dirk,
> >> >> >>
> >> >> >> On Mon, Jan 4, 2016 at 7:46 PM, Dirk Eibach <dirk.eibach@gdsys.cc> wrote:
> >> >> >> > Hi Bin,
> >> >> >> >
> >> >> >> >> ...
> >> >> >> >> The simple fix is to change change iocon to a more larger size since
> >> >> >> >> it has a 64MB flash. Dirk, can you please comment?
> >> >> >> >
> >> >> >> > The problem is the flash partition layout, coming from a time where
> >> >> >> > u-boot was an order of magnitude smaller :)
> >> >> >> >
> >> >> >>
> >> >> >> I guess so.
> >> >> >>
> >> >> >> > Updating partition layout in tens of thousands of devices in the field
> >> >> >> > is not an option for us.
> >> >> >> >
> >> >> >>
> >> >> >> I suspect 256KB won't fit anyway, if trying to make use of these new
> >> >> >> U-Boot features,eg: using driver model adds some more footprints too.
> >> >> >> So in your deployment, you just upgrade those devices in the field to
> >> >> >> latest U-Boot (new version) but not changing partition layout, for fix
> >> >> >> only?
> >> >> >
> >> >> > I'm not convinced that we shouldn't be able to be useful in 256KB.
> >> >> > Sure, a kitchen-sink EVM + config will be large but iocon is a defined
> >> >> > production type config.  If we can't make this work, I'm going to be
> >> >> > worried.  I've already gotten some aside pokes about making U-Boot
> >> >> > shrink down when you turn stuff off.
> >> >> >
> >> >> > I want to cycle back to saying that we need to look at ways to
> >> >> > work-around the gcc issue that's keeping a bunch of unused strings in
> >> >> > the resulting binary.
> >> >>
> >> >> So, what's our best way to do with this PR? I am worried that since
> >> >> this iocon board is already at an edge, any ramdom bug fix (to common
> >> >> codes) in the future could be the next victim.
> >> >
> >> > For this PR, I think we need to push the fdt patch in question out and
> >> > for the next release look at splitting up common/fdt_support.c into
> >> > logical chunks.
> >> >
> >>
> >> Do anyone volunteer to do this "splitting up common/fdt_support.c into
> >> logical chunks"? I still cannot make ELDK work in my env thus cannot
> >> make any further investigation :(
> >
> > I'll put it on my TODO list.  I'll leave ELDK support up to the denx
> > folks.
> 
> Maybe Bin can make a patch to disable Ethernet on iocon and apply
> before the fdt patch? Or would we rather wait on this until you rework
> the fdt_support? Or just rebase this pr and apply as is?

Applied to u-boot/master, thanks!

-- 
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/20160114/61348e1d/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Tom Rini]

On Mon, Jan 04, 2016 at 11:56:34AM +0800, Bin Meng wrote:

[snip]
> Still downloading ELDK toolchains so cannot comment ELDK compiler
> behavior :) One question, what's our recommended toolchains for
> U-Boot? I have been using kernel.org toolchains as mentioned in the
> buildman doc and some other ones mentioned in the moveconfig doc.

Well, the way I look at it we have two answers:
1) In general, any sane for your architecture gcc 4.x or later should
work.  I'm not going to test every possible combination here but
maintainers (who might have less visible needs like hey, our product
uses toolchain X, so I need to use it) may also say their board needs to
work with toolchain X.
2) To me, ELDK current release, current kernel.org toolchains and
current commodity distro (Debian, Fedora, SuSE, etc) toolchains should
work too.

I personally use ELDK 5.6 or PowerPC and MIPS, kernel.org for most
everything else and Debian 8 arm-none-eabi (gcc 4.8.x) as that does both
armv7 and armv7m, and then Debian/Unstable gcc 5.x for
x86/aarch64/arm/sandbox/powerpc.

-- 
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/20160104/981ea653/attachment.sig>

[U-Boot] Pull request: u-boot-net

[Joe Hershberger]

Hi Wolfgang,

Please pull following commits:

The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5:
  Wolfgang Denk (1):
        Prepare v2012.04-rc1

are available in the git repository at:

  git://git.denx.de/u-boot-net.git master

Amit Virdi (1):
      net/designware: Change timeout loop implementation

Armando Visconti (2):
      net/designware: Consecutive writes must have delay
      net/designware: Set ANAR to 0x1e1

Eric Miao (1):
      net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back

Joe Hershberger (1):
      Update net subsystem maintainer in doc/git-mailrc

Stefan Bigler (1):
      mvgbe: remove warning for unused methods

Stephan Linz (4):
      net: ll_temac: Add LL TEMAC driver to u-boot
      microblaze: Enable several ethernet driver compilation
      microblaze: Add faked LL_TEMAC driver configuration
      microblaze: Wire up LL_TEMAC driver initialization

Vikas Manocha (1):
      net/designware: Program phy registers when auto-negotiation is ON

Vipin KUMAR (3):
      net/designware: Fix to restore hw mac address
      net/designware: Fix the max frame length size
      net/designware: Phy address fix

Vipin Kumar (1):
      net/designware: Try configuring phy on each dw_eth_init

 board/xilinx/microblaze-generic/config.mk          |    6 +-
 .../xilinx/microblaze-generic/microblaze-generic.c |   36 ++
 board/xilinx/microblaze-generic/xparameters.h      |   12 +-
 doc/git-mailrc                                     |    3 +-
 drivers/net/Makefile                               |    2 +
 drivers/net/designware.c                           |  128 +++++--
 drivers/net/designware.h                           |    3 +-
 drivers/net/mvgbe.c                                |    2 +
 drivers/net/xilinx_ll_temac.c                      |  399 ++++++++++++++++++++
 drivers/net/xilinx_ll_temac.h                      |  310 +++++++++++++++
 drivers/net/xilinx_ll_temac_fifo.c                 |  143 +++++++
 drivers/net/xilinx_ll_temac_fifo.h                 |  122 ++++++
 drivers/net/xilinx_ll_temac_mdio.c                 |  180 +++++++++
 drivers/net/xilinx_ll_temac_mdio.h                 |   53 +++
 drivers/net/xilinx_ll_temac_sdma.c                 |  370 ++++++++++++++++++
 drivers/net/xilinx_ll_temac_sdma.h                 |  281 ++++++++++++++
 include/configs/microblaze-generic.h               |   11 +-
 include/netdev.h                                   |   12 +
 net/eth.c                                          |    3 +-
 19 files changed, 2025 insertions(+), 51 deletions(-)
 create mode 100644 drivers/net/xilinx_ll_temac.c
 create mode 100644 drivers/net/xilinx_ll_temac.h
 create mode 100644 drivers/net/xilinx_ll_temac_fifo.c
 create mode 100644 drivers/net/xilinx_ll_temac_fifo.h
 create mode 100644 drivers/net/xilinx_ll_temac_mdio.c
 create mode 100644 drivers/net/xilinx_ll_temac_mdio.h
 create mode 100644 drivers/net/xilinx_ll_temac_sdma.c
 create mode 100644 drivers/net/xilinx_ll_temac_sdma.h

[U-Boot] Pull request: u-boot-net

[Wolfgang Denk]

Dear Joe Hershberger,

In message <CANr=Z=aW+S-+zhLMRZuprznSwYcD36z5wtJG1G=rx2POGt5i0Q@mail.gmail.com> you wrote:
> Hi Wolfgang,
> 
> Please pull following commits:
> 
> The following changes since commit c008b6f6dd6b8965e9a7654ffbce75bb9ff7a3b5:
>   Wolfgang Denk (1):
>         Prepare v2012.04-rc1
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-net.git master
> 
> Amit Virdi (1):
>       net/designware: Change timeout loop implementation
> 
> Armando Visconti (2):
>       net/designware: Consecutive writes must have delay
>       net/designware: Set ANAR to 0x1e1
> 
> Eric Miao (1):
>       net/eth.c: fix eth_write_hwaddr() to use dev->enetaddr as fall back
> 
> Joe Hershberger (1):
>       Update net subsystem maintainer in doc/git-mailrc
> 
> Stefan Bigler (1):
>       mvgbe: remove warning for unused methods
> 
> Stephan Linz (4):
>       net: ll_temac: Add LL TEMAC driver to u-boot
>       microblaze: Enable several ethernet driver compilation
>       microblaze: Add faked LL_TEMAC driver configuration
>       microblaze: Wire up LL_TEMAC driver initialization
> 
> Vikas Manocha (1):
>       net/designware: Program phy registers when auto-negotiation is ON
> 
> Vipin KUMAR (3):
>       net/designware: Fix to restore hw mac address
>       net/designware: Fix the max frame length size
>       net/designware: Phy address fix
> 
> Vipin Kumar (1):
>       net/designware: Try configuring phy on each dw_eth_init
> 
>  board/xilinx/microblaze-generic/config.mk          |    6 +-
>  .../xilinx/microblaze-generic/microblaze-generic.c |   36 ++
>  board/xilinx/microblaze-generic/xparameters.h      |   12 +-
>  doc/git-mailrc                                     |    3 +-
>  drivers/net/Makefile                               |    2 +
>  drivers/net/designware.c                           |  128 +++++--
>  drivers/net/designware.h                           |    3 +-
>  drivers/net/mvgbe.c                                |    2 +
>  drivers/net/xilinx_ll_temac.c                      |  399 ++++++++++++++++++++
>  drivers/net/xilinx_ll_temac.h                      |  310 +++++++++++++++
>  drivers/net/xilinx_ll_temac_fifo.c                 |  143 +++++++
>  drivers/net/xilinx_ll_temac_fifo.h                 |  122 ++++++
>  drivers/net/xilinx_ll_temac_mdio.c                 |  180 +++++++++
>  drivers/net/xilinx_ll_temac_mdio.h                 |   53 +++
>  drivers/net/xilinx_ll_temac_sdma.c                 |  370 ++++++++++++++++++
>  drivers/net/xilinx_ll_temac_sdma.h                 |  281 ++++++++++++++
>  include/configs/microblaze-generic.h               |   11 +-
>  include/netdev.h                                   |   12 +
>  net/eth.c                                          |    3 +-
>  19 files changed, 2025 insertions(+), 51 deletions(-)
>  create mode 100644 drivers/net/xilinx_ll_temac.c
>  create mode 100644 drivers/net/xilinx_ll_temac.h
>  create mode 100644 drivers/net/xilinx_ll_temac_fifo.c
>  create mode 100644 drivers/net/xilinx_ll_temac_fifo.h
>  create mode 100644 drivers/net/xilinx_ll_temac_mdio.c
>  create mode 100644 drivers/net/xilinx_ll_temac_mdio.h
>  create mode 100644 drivers/net/xilinx_ll_temac_sdma.c
>  create mode 100644 drivers/net/xilinx_ll_temac_sdma.h

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
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
"The value of marriage is not that adults produce children, but  that
children produce adults."                            - Peter De Vries