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

Wed Oct 17 12:27:19 PDT 2018

On Wed, Oct 17, 2018 at 12:25 PM Denys Dmytriyenko <denys at ti.com> wrote:
>
> On Wed, Oct 17, 2018 at 08:00:52AM -0700, Khem Raj wrote:
> > 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 theEven if this change is not acceptable upstream, I would prefer it locally in
meta-ti recipe, instead of disabling more features to free up 5-6KB in
SPL. 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
>
> Even if this change is not acceptable upstream, I would prefer it locally in
> meta-ti recipe, instead of disabling more features to free up 5-6KB in SPL.

this is a distro level change. meta-ti is not appropriate place to decide that

>
> --
> Denys