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

[Khem Raj]

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

>
>
> Thanks.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-ti/attachments/20181016/1ec6c23b/attachment.html>