On Tue, Oct 16, 2018 at 5:37 PM Denys Dmytriyenko <[email protected]> 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 <[email protected]> wrote:
> > > >
> > > > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <[email protected]> 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 <[email protected]>
> > > > > > 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 <[email protected]>
> > > > > > > > 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
> > > > > > > > > > <[email protected]> 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
> > > > > > > > > > > > <[email protected]> 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
--
_______________________________________________
meta-ti mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-ti
