[meta-ti] [PATCH] beaglebone.conf: temporarily use generic am335x_evm_config for U-boot

Wed Oct 17 08:00:52 PDT 2018

On Wed, Oct 17, 2018 at 4:26 AM Tom Rini <trini at konsulko.com> wrote:

> On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro at socionext.com> wrote:
> >
> > > Hi.
> > >
> > > > -----Original Message-----
> > > > From: Tom Rini [mailto:trini at konsulko.com]
> > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > To: Denys Dmytriyenko <denys at ti.com>; Yamada, Masahiro/山田 真弘
> > > > <yamada.masahiro at socionext.com>
> > > > Cc: Khem Raj <raj.khem at gmail.com>; meta-ti at yoctoproject.org
> > > > Subject: Re: [meta-ti] [PATCH] beaglebone.conf: temporarily use
> generic
> > > > am335x_evm_config for U-boot
> > > >
> > > > On Tue, Oct 16, 2018 at 02:38:28PM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Oct 16, 2018 at 02:29:00PM -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Oct 16, 2018 at 11:11:36AM -0700, Khem Raj wrote:
> > > > > > > On Tue, Oct 16, 2018 at 9:42 AM Tom Rini <trini at konsulko.com>
> > > wrote:
> > > > > > > >
> > > > > > > > On Sun, Oct 14, 2018 at 10:07:45PM -0700, Khem Raj wrote:
> > > > > > > > > On Sun, Oct 14, 2018 at 12:24 PM Denys Dmytriyenko <
> > > denys at ti.com>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Sat, Oct 13, 2018 at 01:17:12AM -0700, Khem Raj wrote:
> > > > > > > > > > > On Fri, Oct 12, 2018 at 8:00 PM Denys Dmytriyenko <
> > > denys at ti.com>
> > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > There have been reports recently that
> > > am335x_beaglebone_config
> > > > generates bad SPL.
> > > > > > > > > > > > Until that is debugged and fixed, use generic
> > > am335x_evm_config
> > > > that covers all
> > > > > > > > > > > > AM335x platforms, including BeagleBone variants.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > it fails to link
> > > > > > > > > > >
> > > > > > > > > > > | arm-yoe-linux-gnueabi-ld.bfd: u-boot-spl section
> > > `.rodata'
> > > > will not
> > > > > > > > > > > fit in region `.sram'
> > > > > > > > > > > | arm-yoe-linux-gnueabi-ld.bfd: region `.sram'
> overflowed
> > > > by 5772 bytes
> > > > > > > > > > > | make[2]: ***
> > > >
> [/mnt/a/yoe/build/tmp/work/beaglebone-yoe-linux-gnueabi/u-boot-ti-stag
> > > > ing/2018.01+gitAUTOINC+2cc52408bf-r24/git/scripts/Makefile.spl:349:
> > > > > > > > > > > spl/u-boot-spl] Error 1
> > > > > > > > > >
> > > > > > > > > > FWIW, just built u-boot-ti-staging with gcc7 and gcc8
> from
> > > oe-core,
> > > > as well as
> > > > > > > > > > Linaro gcc7 - no problems.
> > > > > > > > >
> > > > > > > > > My distro inherits poky policies, and on master it now
> inherits
> > > > > > > > > hardening policies ( security flags) by defaults
> > > > > > > > > do you happen to test poky ?
> > > > > > > >
> > > > > > > > I think we want to take a look at which of the security flags
> > > really
> > > > > > > > make sense to use in this context.  Thanks!
> > > > > > > >
> > > > > > >
> > > > > > > there could be more to it, since the distro uses thumb2 ISA by
> > > > > > > default, I am not sure
> > > > > > > if u-boot overrides that and builds using arm mode ISA always
> but
> > > > > > > something to consider, I saw several reports about u-boot
> > > overflowing
> > > > > > > sram sections and most of
> > > > > > > the solutions were "oh it works for me" or at the best your
> > > toolchain
> > > > > > > is different then mine. here is mine use it and move on.
> > > > > >
> > > > > > Khem,
> > > > > >
> > > > > > Well, FWIW, Tom and I are very familiar with this issue. As a
> matter
> > > > of fact,
> > > > > > I first encountered it almost 2 years ago and had to prove
> there's
> > > such
> > > > an
> > > > > > issue, because everyone was saying it works for them, something
> must
> > > > be wrong
> > > > > > with my OE builds... :)
> > > > > >
> > > > > > While .sram region is very limited, the issue is exacerbated by
> the
> > > > fact that
> > > > > > all debug symbols from macros like __FILE__ are ended up in that
> > > section
> > > > as
> > > > > > well. So, the longer your build path, the larger the section
> becomes.
> > > > Once I
> > > > > > had instructions to reproduce the failure here internally with a
> > > series
> > > > of
> > > > > > long-named nested directories like aaaaaa and bbbbbb, Nishanth
> > > started
> > > > this
> > > > > > thread on U-boot mailing list:
> > > > > > https://lists.denx.de/pipermail/u-boot/2017-March/285031.html
> > > > > >
> > > > > > We've had the corresponding bug open internally all this time,
> while
> > > > adding
> > > > > > workarounds to limit .sram section size by other means, like
> > > disabling
> > > > some
> > > > > > options to reduce the code size. Your patch is one of those
> > > workarounds...
> > > > > >
> > > > > > But we've been patiently waiting for the following feature to
> come
> > > into
> > > > gcc to
> > > > > > fix the issue properly:
> > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268
> > > > > >
> > > > > > Since it's now part of gcc8, we should be able to use it. Not
> sure
> > > how
> > > > to keep
> > > > > > gcc7 backward compatibility though...
> > > > >
> > > > > BTW, there were few attempts to "fix" it in U-boot as well, such as
> > > [1],
> > > > but I
> > > > > don't believe they got accepted. Tom?
> > > > >
> > > > > [1] https://patchwork.ozlabs.org/cover/825356/
> > > >
> > > > I think the end result was waiting on the kernel community to agree
> on a
> > > > path forward for Kbuild and then bring that back.
> > >
> > >
> > >
> > > U-Boot now supports -fmacro-prefix-map, so GCC 8 is OK.
> > > (see commit 1eb2e71ed)
> > >
> > > For GCC 7 or older, sorry, I have no idea what to do.
> > > My patch set [1] was an ugly hack,
> > > and wrong in the first place.
> > >
> > > What I can suggest is, please use GCC 8.
> >
> >
> > Yeah I saw that but this patch is not their in 2018.01 release that TI
> fork
> > is based on regardless I backported this patch to this version it did not
> > bring the size below mark
> > I think it’s because we are using hardened toolchain and that enalbles
> > extra options to enable pie and ssp since these options get added to CC
> > they get passed into uboot straight
> >
> > I think we should just disable security flags for u boot in OE and may be
> > uboot make system should append fno-pie fno-stack-protector to nullify
> > these options
>
> OK, do you want to submit a patch for that or should I do one and just
> Suggested-by you?  Thanks!

This would not be acceptable change since it changes how we build gcc
itself secondly it does not happen for master uboot

However if this works then we need to understand why it increas e the size

>
> --
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20181017/b7eaf9b1/attachment.html>