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

[Khem Raj]

On Tue, Oct 16, 2018 at 5:37 PM Denys Dmytriyenko <denys at ti.com> wrote:
>
> On Tue, Oct 16, 2018 at 08:26:45PM -0400, Denys Dmytriyenko wrote:
> > On Tue, Oct 16, 2018 at 02:19:36PM -0700, Khem Raj wrote:
> > > On Tue, Oct 16, 2018 at 12:20 PM Khem Raj <raj.khem at gmail.com> wrote:
> > > >
> > > > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys at ti.com> wrote:
> > > > >
> > > > > On Tue, Oct 16, 2018 at 11:50:36AM -0700, Khem Raj wrote:
> > > > > > On Tue, Oct 16, 2018 at 11:29 AM Denys Dmytriyenko <denys at ti.com> 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-staging/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...
> > > > > >
> > > > > > dumping absolute file name strings into SPL seems a waste of space to
> > > > > > me, but I will leave that out for now. Moreover it exposes build paths
> > > > > > into binaries that user may not be interested to share
> > > > > >
> > > > > > -ffile-prefix-map has been in OE toolchains since gcc6 and I think we
> > > > > > are already using it for kernel builds. We can probably enhance uboot
> > > > > > recipes in OE-Core to
> > > > > > use this option if compiler supports it. That solves my problem.
> > > > >
> > > > > Yeah, extending that from kernel to u-boot would be nice.
> > > > > Unfortunately, our products use Linaro gcc7 on rocko for now. Planning to
> > > > > migrate to gcc8 on thud soon...
> > > >
> > > > we can check for the option before using it so atleast it will not
> > > > break older toolchains more than what they are already broken.
> > >
> > > I added -ffile-prefix-map locally just with this option added it did
> > > not fix the problem.
> >
> > So, I tried Poky and I do see it overflow by 5-6 KB, which is quite a lot.
> > Though disabling security flags just for u-boot didn't change it a bit.
> > Something else is going on. I'm now rebuilding Poky with security flags
> > disabled globally...
>
> Hmm, disabling security flags globally and rebuilding toolchain and then
> u-boot "fixes" it. Wonder what would cause the same code to change by 6KB.

security flags also enable PIE in gcc by default. secondly it also
enable ssp can you try setting

SECURITY_LDFLAGS = ""
SECURITY_STACK_PROTECTOR = ""

in uboot recipe and see if that helps.

If it does not then add

SECURITY_CFLAGS = "${SECURITY_NOPIE_CFLAGS}"

and see if that helps