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

[Denys Dmytriyenko]

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...

-- 
Denys