On Wed, Oct 17, 2018 at 02:39:15AM +0000, [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. Ah yes, thanks! -- Tom -- _______________________________________________ meta-ti mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-ti
