On Tue, Oct 16, 2018 at 7:39 PM <[email protected]> wrote:
> Hi. > > > -----Original Message----- > > From: Tom Rini [mailto:[email protected]] > > Sent: Wednesday, October 17, 2018 3:59 AM > > To: Denys Dmytriyenko <[email protected]>; Yamada, Masahiro/山田 真弘 > > <[email protected]> > > Cc: Khem Raj <[email protected]>; [email protected] > > 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 <[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-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. > >
-- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
