<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 16, 2018 at 7:39 PM <<a href="mailto:yamada.masahiro@socionext.com">yamada.masahiro@socionext.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi.<br>
<br>
> -----Original Message-----<br>
> From: Tom Rini [mailto:<a href="mailto:trini@konsulko.com" target="_blank">trini@konsulko.com</a>]<br>
> Sent: Wednesday, October 17, 2018 3:59 AM<br>
> To: Denys Dmytriyenko <<a href="mailto:denys@ti.com" target="_blank">denys@ti.com</a>>; Yamada, Masahiro/山田 çœŸå¼˜<br>
> <<a href="mailto:yamada.masahiro@socionext.com" target="_blank">yamada.masahiro@socionext.com</a>><br>
> Cc: Khem Raj <<a href="mailto:raj.khem@gmail.com" target="_blank">raj.khem@gmail.com</a>>; <a href="mailto:meta-ti@yoctoproject.org" target="_blank">meta-ti@yoctoproject.org</a><br>
> Subject: Re: [meta-ti] [PATCH] beaglebone.conf: temporarily use generic<br>
> am335x_evm_config for U-boot<br>
> <br>
> On Tue, Oct 16, 2018 at 02:38:28PM -0400, Denys Dmytriyenko wrote:<br>
> > On Tue, Oct 16, 2018 at 02:29:00PM -0400, Denys Dmytriyenko wrote:<br>
> > > On Tue, Oct 16, 2018 at 11:11:36AM -0700, Khem Raj wrote:<br>
> > > > On Tue, Oct 16, 2018 at 9:42 AM Tom Rini <<a href="mailto:trini@konsulko.com" target="_blank">trini@konsulko.com</a>> wrote:<br>
> > > > ><br>
> > > > > On Sun, Oct 14, 2018 at 10:07:45PM -0700, Khem Raj wrote:<br>
> > > > > > On Sun, Oct 14, 2018 at 12:24 PM Denys Dmytriyenko <<a href="mailto:denys@ti.com" target="_blank">denys@ti.com</a>><br>
> wrote:<br>
> > > > > > ><br>
> > > > > > > On Sat, Oct 13, 2018 at 01:17:12AM -0700, Khem Raj wrote:<br>
> > > > > > > > On Fri, Oct 12, 2018 at 8:00 PM Denys Dmytriyenko <<a href="mailto:denys@ti.com" target="_blank">denys@ti.com</a>><br>
> wrote:<br>
> > > > > > > > ><br>
> > > > > > > > > There have been reports recently that am335x_beaglebone_config<br>
> generates bad SPL.<br>
> > > > > > > > > Until that is debugged and fixed, use generic am335x_evm_config<br>
> that covers all<br>
> > > > > > > > > AM335x platforms, including BeagleBone variants.<br>
> > > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > it fails to link<br>
> > > > > > > ><br>
> > > > > > > > | arm-yoe-linux-gnueabi-ld.bfd: u-boot-spl section `.rodata'<br>
> will not<br>
> > > > > > > > fit in region `.sram'<br>
> > > > > > > > | arm-yoe-linux-gnueabi-ld.bfd: region `.sram' overflowed<br>
> by 5772 bytes<br>
> > > > > > > > | make[2]: ***<br>
> [/mnt/a/yoe/build/tmp/work/beaglebone-yoe-linux-gnueabi/u-boot-ti-stag<br>
> ing/2018.01+gitAUTOINC+2cc52408bf-r24/git/scripts/Makefile.spl:349:<br>
> > > > > > > > spl/u-boot-spl] Error 1<br>
> > > > > > ><br>
> > > > > > > FWIW, just built u-boot-ti-staging with gcc7 and gcc8 from oe-core,<br>
> as well as<br>
> > > > > > > Linaro gcc7 - no problems.<br>
> > > > > ><br>
> > > > > > My distro inherits poky policies, and on master it now inherits<br>
> > > > > > hardening policies ( security flags) by defaults<br>
> > > > > > do you happen to test poky ?<br>
> > > > ><br>
> > > > > I think we want to take a look at which of the security flags really<br>
> > > > > make sense to use in this context.  Thanks!<br>
> > > > ><br>
> > > ><br>
> > > > there could be more to it, since the distro uses thumb2 ISA by<br>
> > > > default, I am not sure<br>
> > > > if u-boot overrides that and builds using arm mode ISA always but<br>
> > > > something to consider, I saw several reports about u-boot overflowing<br>
> > > > sram sections and most of<br>
> > > > the solutions were "oh it works for me" or at the best your toolchain<br>
> > > > is different then mine. here is mine use it and move on.<br>
> > ><br>
> > > Khem,<br>
> > ><br>
> > > Well, FWIW, Tom and I are very familiar with this issue. As a matter<br>
> of fact,<br>
> > > I first encountered it almost 2 years ago and had to prove there's such<br>
> an<br>
> > > issue, because everyone was saying it works for them, something must<br>
> be wrong<br>
> > > with my OE builds... :)<br>
> > ><br>
> > > While .sram region is very limited, the issue is exacerbated by the<br>
> fact that<br>
> > > all debug symbols from macros like __FILE__ are ended up in that section<br>
> as<br>
> > > well. So, the longer your build path, the larger the section becomes.<br>
> Once I<br>
> > > had instructions to reproduce the failure here internally with a series<br>
> of<br>
> > > long-named nested directories like aaaaaa and bbbbbb, Nishanth started<br>
> this<br>
> > > thread on U-boot mailing list:<br>
> > > <a href="https://lists.denx.de/pipermail/u-boot/2017-March/285031.html" rel="noreferrer" target="_blank">https://lists.denx.de/pipermail/u-boot/2017-March/285031.html</a><br>
> > ><br>
> > > We've had the corresponding bug open internally all this time, while<br>
> adding<br>
> > > workarounds to limit .sram section size by other means, like disabling<br>
> some<br>
> > > options to reduce the code size. Your patch is one of those workarounds...<br>
> > ><br>
> > > But we've been patiently waiting for the following feature to come into<br>
> gcc to<br>
> > > fix the issue properly:<br>
> > > <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268</a><br>
> > ><br>
> > > Since it's now part of gcc8, we should be able to use it. Not sure how<br>
> to keep<br>
> > > gcc7 backward compatibility though...<br>
> ><br>
> > BTW, there were few attempts to "fix" it in U-boot as well, such as [1],<br>
> but I<br>
> > don't believe they got accepted. Tom?<br>
> ><br>
> > [1] <a href="https://patchwork.ozlabs.org/cover/825356/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/cover/825356/</a><br>
> <br>
> I think the end result was waiting on the kernel community to agree on a<br>
> path forward for Kbuild and then bring that back.<br>
<br>
<br>
<br>
U-Boot now supports -fmacro-prefix-map, so GCC 8 is OK.<br>
(see commit 1eb2e71ed)<br>
<br>
For GCC 7 or older, sorry, I have no idea what to do.<br>
My patch set [1] was an ugly hack,<br>
and wrong in the first place.<br>
<br>
What I can suggest is, please use GCC 8.</blockquote><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto">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 </div><div dir="auto"><br></div><div dir="auto">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</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Thanks.<br>
<br>
</blockquote></div></div>