[U-Boot] [ARM] one warning left for all ARM boards

[U-Boot] [ARM] one warning left for all ARM boards

[Albert ARIBAUD]

Hi all,

With the latest commits on u-boot/master, two obnoxious "attention"
messages were removed from ARM builds, but one still remains:

attention : -fstack-usage not supported for this target [enabled by
default]

This is with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5).

doc/SPL/README.omap3 does indeed say that not all GCC releases have
-fstack-usage, and commit 4a30f1e8 from Tom Rini (Cc:) says it tests
for the option, but apparently testing for the option is not the same as
testing for the option on a given target...

How do we get rid of those warnings? Right now they appear for every
single ARM board built.

Amicalement,
-- 
Albert.

[U-Boot] [ARM] one warning left for all ARM boards

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> 
> With the latest commits on u-boot/master, two obnoxious "attention"
> messages were removed from ARM builds, but one still remains:
> 
> attention : -fstack-usage not supported for this target [enabled by
> default]

As recommended on the ML I reverted the commit that caused this
trouble, waiting to see a new (more carefully tested) version to be
applied instead.

At the moment ARM is build clean, as far as I can tell.

If nobody adds any new pull requests very soon now, I'll go for -rc1.

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
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

[U-Boot] [ARM] one warning left for all ARM boards

[Tom Rini]

On Mon, Jul 09, 2012 at 09:48:18PM +0200, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
> 
> In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > 
> > With the latest commits on u-boot/master, two obnoxious "attention"
> > messages were removed from ARM builds, but one still remains:
> > 
> > attention : -fstack-usage not supported for this target [enabled by
> > default]
> 
> As recommended on the ML I reverted the commit that caused this
> trouble, waiting to see a new (more carefully tested) version to be
> applied instead.
> 
> At the moment ARM is build clean, as far as I can tell.
> 
> If nobody adds any new pull requests very soon now, I'll go for -rc1.

The best version of this patch, which won't add new warnings is:
http://patchwork.ozlabs.org/patch/169561/ and it fixes both the reported
problem by being in assembly and avoiding the -fstack-usage issue (as
that flag doesn't deal with assembly files).  It's also a slight
improvement in that we go from a fn_foo_default + alias for weak to just
declaring a fn_foo as weak.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120709/6373103e/attachment.pgp>

[U-Boot] [ARM] one warning left for all ARM boards

[Albert ARIBAUD]

Hi Wolfgang,

On Mon, 09 Jul 2012 21:48:18 +0200, Wolfgang Denk <wd@denx.de> wrote:
> Dear Albert ARIBAUD,
> 
> In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > 
> > With the latest commits on u-boot/master, two obnoxious "attention"
> > messages were removed from ARM builds, but one still remains:
> > 
> > attention : -fstack-usage not supported for this target [enabled by
> > default]
> 
> As recommended on the ML I reverted the commit that caused this
> trouble, waiting to see a new (more carefully tested) version to be
> applied instead.
> 
> At the moment ARM is build clean, as far as I can tell.
> 
> If nobody adds any new pull requests very soon now, I'll go for -rc1.

I've received two pull requests that I have taken in, rebased on the
u-boot/master. I have a regression build running, if you can wait until
at most tomorrow morning.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [ARM] one warning left for all ARM boards

[Tom Rini]

On Mon, Jul 09, 2012 at 09:48:18PM +0200, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
> 
> In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > 
> > With the latest commits on u-boot/master, two obnoxious "attention"
> > messages were removed from ARM builds, but one still remains:
> > 
> > attention : -fstack-usage not supported for this target [enabled by
> > default]
> 
> As recommended on the ML I reverted the commit that caused this
> trouble, waiting to see a new (more carefully tested) version to be
> applied instead.
> 
> At the moment ARM is build clean, as far as I can tell.
> 
> If nobody adds any new pull requests very soon now, I'll go for -rc1.

What do we want to do about the USB issue (on ARM platforms, with EHCI,
with >32byte alignment requirements, if dcache isn't build-time
disabled, USB is unusable, a change from previous releases), for this
release?  Are we going to hope the alignment issues can be flushed out
and fixed well enough before the final release?  Should we go with
disable the dcache now, continue working on it for the next?

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

[U-Boot] [ARM] one warning left for all ARM boards

[Albert ARIBAUD]

Hi Tom,

On Mon, 9 Jul 2012 14:07:22 -0700, Tom Rini <trini@ti.com> wrote:
> On Mon, Jul 09, 2012 at 09:48:18PM +0200, Wolfgang Denk wrote:
> > Dear Albert ARIBAUD,
> > 
> > In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > > 
> > > With the latest commits on u-boot/master, two obnoxious "attention"
> > > messages were removed from ARM builds, but one still remains:
> > > 
> > > attention : -fstack-usage not supported for this target [enabled by
> > > default]
> > 
> > As recommended on the ML I reverted the commit that caused this
> > trouble, waiting to see a new (more carefully tested) version to be
> > applied instead.
> > 
> > At the moment ARM is build clean, as far as I can tell.
> > 
> > If nobody adds any new pull requests very soon now, I'll go for -rc1.
> 
> What do we want to do about the USB issue (on ARM platforms, with EHCI,
> with >32byte alignment requirements, if dcache isn't build-time
> disabled, USB is unusable, a change from previous releases), for this
> release?  Are we going to hope the alignment issues can be flushed out
> and fixed well enough before the final release?  Should we go with
> disable the dcache now, continue working on it for the next?

What are the chances that the issue be fixed?

Amicalement,
-- 
Albert.

[U-Boot] [ARM] one warning left for all ARM boards

[Marek Vasut]

Dear Albert ARIBAUD,

> Hi Tom,
> 
> On Mon, 9 Jul 2012 14:07:22 -0700, Tom Rini <trini@ti.com> wrote:
> > On Mon, Jul 09, 2012 at 09:48:18PM +0200, Wolfgang Denk wrote:
> > > Dear Albert ARIBAUD,
> > > 
> > > In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > > > With the latest commits on u-boot/master, two obnoxious "attention"
> > > > messages were removed from ARM builds, but one still remains:
> > > > 
> > > > attention : -fstack-usage not supported for this target [enabled by
> > > > default]
> > > 
> > > As recommended on the ML I reverted the commit that caused this
> > > trouble, waiting to see a new (more carefully tested) version to be
> > > applied instead.
> > > 
> > > At the moment ARM is build clean, as far as I can tell.
> > > 
> > > If nobody adds any new pull requests very soon now, I'll go for -rc1.
> > 
> > What do we want to do about the USB issue (on ARM platforms, with EHCI,
> > with >32byte alignment requirements, if dcache isn't build-time
> > disabled, USB is unusable, a change from previous releases), for this
> > release?  Are we going to hope the alignment issues can be flushed out
> > and fixed well enough before the final release?  Should we go with
> > disable the dcache now, continue working on it for the next?
> 
> What are the chances that the issue be fixed?

Low ... this is some deep crap that's growing through uboot as whole :-( And 
it's not only USB.

> Amicalement,

Best regards,
Marek Vasut

[U-Boot] [ARM] one warning left for all ARM boards

[Tom Rini]

On Tue, Jul 10, 2012 at 03:53:43AM +0200, Marek Vasut wrote:
> Dear Albert ARIBAUD,
> 
> > Hi Tom,
> > 
> > On Mon, 9 Jul 2012 14:07:22 -0700, Tom Rini <trini@ti.com> wrote:
> > > On Mon, Jul 09, 2012 at 09:48:18PM +0200, Wolfgang Denk wrote:
> > > > Dear Albert ARIBAUD,
> > > > 
> > > > In message <20120709174210.0bc0cef5@aari01-12> you wrote:
> > > > > With the latest commits on u-boot/master, two obnoxious "attention"
> > > > > messages were removed from ARM builds, but one still remains:
> > > > > 
> > > > > attention : -fstack-usage not supported for this target [enabled by
> > > > > default]
> > > > 
> > > > As recommended on the ML I reverted the commit that caused this
> > > > trouble, waiting to see a new (more carefully tested) version to be
> > > > applied instead.
> > > > 
> > > > At the moment ARM is build clean, as far as I can tell.
> > > > 
> > > > If nobody adds any new pull requests very soon now, I'll go for -rc1.
> > > 
> > > What do we want to do about the USB issue (on ARM platforms, with EHCI,
> > > with >32byte alignment requirements, if dcache isn't build-time
> > > disabled, USB is unusable, a change from previous releases), for this
> > > release?  Are we going to hope the alignment issues can be flushed out
> > > and fixed well enough before the final release?  Should we go with
> > > disable the dcache now, continue working on it for the next?
> > 
> > What are the chances that the issue be fixed?
> 
> Low ... this is some deep crap that's growing through uboot as whole :-( And 
> it's not only USB.

Then I propose 1, 3, 4, 5, 6 from my v4 series (remove dcache_off
call from ehci-omap.c as it's wrong, build-time disable DCACHE on USB
enabling platforms).  Yes, we're papering over bugs for a release, but
we (a) know we're doing it and (b) are trying to fix them and (c) can't
fix them in time.

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

[U-Boot] [ARM] one warning left for all ARM boards

[Ilya Yanok]

Hi guys,

On Tue, Jul 10, 2012 at 12:37 PM, Tom Rini <trini@ti.com> wrote:

> > > > What do we want to do about the USB issue (on ARM platforms, with
> EHCI,
> > > > with >32byte alignment requirements, if dcache isn't build-time
> > > > disabled, USB is unusable, a change from previous releases), for this
> > > > release?  Are we going to hope the alignment issues can be flushed
> out
> > > > and fixed well enough before the final release?  Should we go with
> > > > disable the dcache now, continue working on it for the next?
> > >
> > > What are the chances that the issue be fixed?
> >
> > Low ... this is some deep crap that's growing through uboot as whole :-(
> And
> > it's not only USB.
>
> Then I propose 1, 3, 4, 5, 6 from my v4 series (remove dcache_off
> call from ehci-omap.c as it's wrong, build-time disable DCACHE on USB
> enabling platforms).  Yes, we're papering over bugs for a release, but
> we (a) know we're doing it and (b) are trying to fix them and (c) can't
> fix them in time.


I will resend the series this evening. There is no bounce buffering support
so unaligned operations (unaligned address passed by user) are broken but
otherwise I think everything works.

And I'd really like to make runtime cache disabling work again. Probably we
can rename {flush,invalidate}_dcache_range() to
__{flush,invalidate}_dcache_range() and call these functions there we
really need to do these operations regardless of cache being enabled. Then
we could create new {flush,invalidate}_dcache_range() and do if
(dcache_enabled()) check in them,,,

Regards, Ilya.

[U-Boot] [ARM] one warning left for all ARM boards

[Tom Rini]

On Tue, Jul 10, 2012 at 12:46:21PM +0400, Ilya Yanok wrote:
> Hi guys,
> 
> On Tue, Jul 10, 2012 at 12:37 PM, Tom Rini <trini@ti.com> wrote:
> 
> > > > > What do we want to do about the USB issue (on ARM platforms, with
> > EHCI,
> > > > > with >32byte alignment requirements, if dcache isn't build-time
> > > > > disabled, USB is unusable, a change from previous releases), for this
> > > > > release?  Are we going to hope the alignment issues can be flushed
> > out
> > > > > and fixed well enough before the final release?  Should we go with
> > > > > disable the dcache now, continue working on it for the next?
> > > >
> > > > What are the chances that the issue be fixed?
> > >
> > > Low ... this is some deep crap that's growing through uboot as whole :-(
> > And
> > > it's not only USB.
> >
> > Then I propose 1, 3, 4, 5, 6 from my v4 series (remove dcache_off
> > call from ehci-omap.c as it's wrong, build-time disable DCACHE on USB
> > enabling platforms).  Yes, we're papering over bugs for a release, but
> > we (a) know we're doing it and (b) are trying to fix them and (c) can't
> > fix them in time.
> 
> 
> I will resend the series this evening. There is no bounce buffering support
> so unaligned operations (unaligned address passed by user) are broken but
> otherwise I think everything works.
> 
> And I'd really like to make runtime cache disabling work again. Probably we
> can rename {flush,invalidate}_dcache_range() to
> __{flush,invalidate}_dcache_range() and call these functions there we
> really need to do these operations regardless of cache being enabled. Then
> we could create new {flush,invalidate}_dcache_range() and do if
> (dcache_enabled()) check in them,,,

We've got a release date now.  If you think you can get this done and
tested in time, OK.  But if we don't have this by -rc2 time we need to
put in the big stupid fix instead (since not all distributions come to
me with questions about things, I fear some may say USB doesn't work and
hold back for who knows how long).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120710/99566c0c/attachment.pgp>