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

[Khem Raj]

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.