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

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

[Denys Dmytriyenko]

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.

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
 conf/machine/beaglebone.conf | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
index 49edfd6..2514792 100644
--- a/conf/machine/beaglebone.conf
+++ b/conf/machine/beaglebone.conf
@@ -13,7 +13,8 @@ MACHINE_GUI_CLASS = "bigscreen"
 
 SERIAL_CONSOLE = "115200 ttyS0"
 
-UBOOT_MACHINE = "am335x_boneblack_config"
+# fall back on generic am335x_evm_config for now
+#UBOOT_MACHINE = "am335x_boneblack_config"
 
 WKS_FILE = "sdimage-bootpart.wks"
 IMAGE_BOOT_FILES = "MLO u-boot.img"
-- 
2.7.4

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

[Khem Raj]

On Fri, Oct 12, 2018 at 8:00 PM Denys Dmytriyenko <denys@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-staging/2018.01+gitAUTOINC+2cc52408bf-r24/git/scripts/Makefile.spl:349:
spl/u-boot-spl] Error 1
|

> Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> ---
>  conf/machine/beaglebone.conf | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
> index 49edfd6..2514792 100644
> --- a/conf/machine/beaglebone.conf
> +++ b/conf/machine/beaglebone.conf
> @@ -13,7 +13,8 @@ MACHINE_GUI_CLASS = "bigscreen"
>
>  SERIAL_CONSOLE = "115200 ttyS0"
>
> -UBOOT_MACHINE = "am335x_boneblack_config"
> +# fall back on generic am335x_evm_config for now
> +#UBOOT_MACHINE = "am335x_boneblack_config"
>
>  WKS_FILE = "sdimage-bootpart.wks"
>  IMAGE_BOOT_FILES = "MLO u-boot.img"
> --
> 2.7.4
>
> --
> _______________________________________________
> meta-ti mailing list
> meta-ti@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

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

[Denys Dmytriyenko]

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@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-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.


> > Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> > ---
> >  conf/machine/beaglebone.conf | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
> > index 49edfd6..2514792 100644
> > --- a/conf/machine/beaglebone.conf
> > +++ b/conf/machine/beaglebone.conf
> > @@ -13,7 +13,8 @@ MACHINE_GUI_CLASS = "bigscreen"
> >
> >  SERIAL_CONSOLE = "115200 ttyS0"
> >
> > -UBOOT_MACHINE = "am335x_boneblack_config"
> > +# fall back on generic am335x_evm_config for now
> > +#UBOOT_MACHINE = "am335x_boneblack_config"
> >
> >  WKS_FILE = "sdimage-bootpart.wks"
> >  IMAGE_BOOT_FILES = "MLO u-boot.img"
> > --
> > 2.7.4
> >
> > --
> > _______________________________________________
> > meta-ti mailing list
> > meta-ti@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-ti

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

[Khem Raj]

On Sun, Oct 14, 2018 at 12:24 PM Denys Dmytriyenko <denys@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@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-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 ?
>
>
> > > Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> > > ---
> > >  conf/machine/beaglebone.conf | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
> > > index 49edfd6..2514792 100644
> > > --- a/conf/machine/beaglebone.conf
> > > +++ b/conf/machine/beaglebone.conf
> > > @@ -13,7 +13,8 @@ MACHINE_GUI_CLASS = "bigscreen"
> > >
> > >  SERIAL_CONSOLE = "115200 ttyS0"
> > >
> > > -UBOOT_MACHINE = "am335x_boneblack_config"
> > > +# fall back on generic am335x_evm_config for now
> > > +#UBOOT_MACHINE = "am335x_boneblack_config"
> > >
> > >  WKS_FILE = "sdimage-bootpart.wks"
> > >  IMAGE_BOOT_FILES = "MLO u-boot.img"
> > > --
> > > 2.7.4
> > >
> > > --
> > > _______________________________________________
> > > meta-ti mailing list
> > > meta-ti@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/meta-ti

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

[Khem Raj]

On Sun, Oct 14, 2018 at 10:07 PM Khem Raj <raj.khem@gmail.com> wrote:
>
> On Sun, Oct 14, 2018 at 12:24 PM Denys Dmytriyenko <denys@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@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-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 ?

It seems I am not alone, there has been other reports of similar
issues and some combos work some dont
I have ported this patch

http://e2e.ti.com/support/processors/f/791/t/733651?PROCESSOR-SDK-AM335X-MLO-and-U-boot-issues-u-boot-spl-section-rodata-will-not-fit-in-region-sram-

and now my build problems are gone,

Added couple of other patches on top for beaglebone, and now I can
boot bbb using meta-ti BSP


> >
> >
> > > > Signed-off-by: Denys Dmytriyenko <denys@ti.com>
> > > > ---
> > > >  conf/machine/beaglebone.conf | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/conf/machine/beaglebone.conf b/conf/machine/beaglebone.conf
> > > > index 49edfd6..2514792 100644
> > > > --- a/conf/machine/beaglebone.conf
> > > > +++ b/conf/machine/beaglebone.conf
> > > > @@ -13,7 +13,8 @@ MACHINE_GUI_CLASS = "bigscreen"
> > > >
> > > >  SERIAL_CONSOLE = "115200 ttyS0"
> > > >
> > > > -UBOOT_MACHINE = "am335x_boneblack_config"
> > > > +# fall back on generic am335x_evm_config for now
> > > > +#UBOOT_MACHINE = "am335x_boneblack_config"
> > > >
> > > >  WKS_FILE = "sdimage-bootpart.wks"
> > > >  IMAGE_BOOT_FILES = "MLO u-boot.img"
> > > > --
> > > > 2.7.4
> > > >
> > > > --
> > > > _______________________________________________
> > > > meta-ti mailing list
> > > > meta-ti@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/meta-ti

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

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@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@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-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!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Khem Raj]

On Tue, Oct 16, 2018 at 9:42 AM Tom Rini <trini@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@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@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-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.

> --
> Tom

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

[Denys Dmytriyenko]

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@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@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@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-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...

-- 
Denys

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

[Denys Dmytriyenko]

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@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@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@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-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...

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/

-- 
Denys

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]

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@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@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@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-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...
> 
> 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.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Tom Rini]

On Wed, Oct 17, 2018 at 02:39:15AM +0000, yamada.masahiro@socionext.com wrote:

> Hi.
> 
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@konsulko.com]
> > Sent: Wednesday, October 17, 2018 3:59 AM
> > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > <yamada.masahiro@socionext.com>
> > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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.

Ah yes, thanks!

-- 
Tom

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 5767 bytes --]

On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:

> Hi.
>
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@konsulko.com]
> > Sent: Wednesday, October 17, 2018 3:59 AM
> > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > <yamada.masahiro@socionext.com>
> > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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.
>
>

[-- Attachment #2: Type: text/html, Size: 8390 bytes --]

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> 
> > Hi.
> >
> > > -----Original Message-----
> > > From: Tom Rini [mailto:trini@konsulko.com]
> > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > <yamada.masahiro@socionext.com>
> > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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

FWIW, as I mentioned earlier, just adding no-security flags to the recipe 
didn't really work. I'm open to more suggestions.

-- 
Denys

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

[Khem Raj]

try setting #GCCPIE = "" in local.conf
On Tue, Oct 16, 2018 at 9:37 PM Denys Dmytriyenko <denys@ti.com> wrote:
>
> On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> >
> > > Hi.
> > >
> > > > -----Original Message-----
> > > > From: Tom Rini [mailto:trini@konsulko.com]
> > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > > <yamada.masahiro@socionext.com>
> > > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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
>
> FWIW, as I mentioned earlier, just adding no-security flags to the recipe
> didn't really work. I'm open to more suggestions.
>
> --
> Denys

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 11:55:24PM -0700, Khem Raj wrote:
> try setting #GCCPIE = "" in local.conf

Yeah, it works, but obviously rebuilds the entire toolchain...


> On Tue, Oct 16, 2018 at 9:37 PM Denys Dmytriyenko <denys@ti.com> wrote:
> >
> > On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> > >
> > > > Hi.
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom Rini [mailto:trini@konsulko.com]
> > > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > > > <yamada.masahiro@socionext.com>
> > > > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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
> >
> > FWIW, as I mentioned earlier, just adding no-security flags to the recipe
> > didn't really work. I'm open to more suggestions.
> >
> > --
> > Denys

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6221 bytes --]

On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> 
> > Hi.
> >
> > > -----Original Message-----
> > > From: Tom Rini [mailto:trini@konsulko.com]
> > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > <yamada.masahiro@socionext.com>
> > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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

OK, do you want to submit a patch for that or should I do one and just
Suggested-by you?  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 6869 bytes --]

On Wed, Oct 17, 2018 at 4:26 AM Tom Rini <trini@konsulko.com> wrote:

> On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> >
> > > Hi.
> > >
> > > > -----Original Message-----
> > > > From: Tom Rini [mailto:trini@konsulko.com]
> > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > > <yamada.masahiro@socionext.com>
> > > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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
>
> OK, do you want to submit a patch for that or should I do one and just
> Suggested-by you?  Thanks!


This would not be acceptable change since it changes how we build gcc
itself secondly it does not happen for master uboot

However if this works then we need to understand why it increas e the size



>
> --
> Tom
>

[-- Attachment #2: Type: text/html, Size: 10549 bytes --]

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

[Denys Dmytriyenko]

On Wed, Oct 17, 2018 at 08:00:52AM -0700, Khem Raj wrote:
> On Wed, Oct 17, 2018 at 4:26 AM Tom Rini <trini@konsulko.com> wrote:
> 
> > On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> > >
> > > > Hi.
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom Rini [mailto:trini@konsulko.com]
> > > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > > > <yamada.masahiro@socionext.com>
> > > > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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
> >
> > OK, do you want to submit a patch for that or should I do one and just
> > Suggested-by you?  Thanks!
> 
> 
> This would not be acceptable change since it changes how we build gcc
> itself secondly it does not happen for master uboot
> 
> However if this works then we need to understand why it increas e the size

Even if this change is not acceptable upstream, I would prefer it locally in 
meta-ti recipe, instead of disabling more features to free up 5-6KB in SPL.

-- 
Denys

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

[Khem Raj]

On Wed, Oct 17, 2018 at 12:25 PM Denys Dmytriyenko <denys@ti.com> wrote:
>
> On Wed, Oct 17, 2018 at 08:00:52AM -0700, Khem Raj wrote:
> > On Wed, Oct 17, 2018 at 4:26 AM Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Oct 16, 2018 at 09:06:27PM -0700, Khem Raj wrote:
> > > > On Tue, Oct 16, 2018 at 7:39 PM <yamada.masahiro@socionext.com> wrote:
> > > >
> > > > > Hi.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Tom Rini [mailto:trini@konsulko.com]
> > > > > > Sent: Wednesday, October 17, 2018 3:59 AM
> > > > > > To: Denys Dmytriyenko <denys@ti.com>; Yamada, Masahiro/山田 真弘
> > > > > > <yamada.masahiro@socionext.com>
> > > > > > Cc: Khem Raj <raj.khem@gmail.com>; meta-ti@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@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@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@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 theEven if this change is not acceptable upstream, I would prefer it locally in
meta-ti recipe, instead of disabling more features to free up 5-6KB in
SPL. 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
> > >
> > > OK, do you want to submit a patch for that or should I do one and just
> > > Suggested-by you?  Thanks!
> >
> >
> > This would not be acceptable change since it changes how we build gcc
> > itself secondly it does not happen for master uboot
> >
> > However if this works then we need to understand why it increas e the size
>
> Even if this change is not acceptable upstream, I would prefer it locally in
> meta-ti recipe, instead of disabling more features to free up 5-6KB in SPL.

this is a distro level change. meta-ti is not appropriate place to decide that

>
> --
> Denys

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

[Denys Dmytriyenko]

On Wed, Oct 17, 2018 at 12:27:19PM -0700, Khem Raj wrote:
> On Wed, Oct 17, 2018 at 12:25 PM Denys Dmytriyenko <denys@ti.com> wrote:
> > > > > 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
> > > >
> > > > OK, do you want to submit a patch for that or should I do one and just
> > > > Suggested-by you?  Thanks!
> > >
> > >
> > > This would not be acceptable change since it changes how we build gcc
> > > itself secondly it does not happen for master uboot
> > >
> > > However if this works then we need to understand why it increas e the size
> >
> > Even if this change is not acceptable upstream, I would prefer it locally in
> > meta-ti recipe, instead of disabling more features to free up 5-6KB in SPL.
> 
> this is a distro level change. meta-ti is not appropriate place to decide that

Are we talking about passing fno-pie and fno-stack-protector to U-boot build 
that you suggested above? That is what I'm referring here. It can be BBB 
specific patch. That is until we figure out why it grows code so much...

-- 
Denys

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

[Khem Raj]

On Wed, Oct 17, 2018 at 12:37 PM Denys Dmytriyenko <denys@ti.com> wrote:
>
> On Wed, Oct 17, 2018 at 12:27:19PM -0700, Khem Raj wrote:
> > On Wed, Oct 17, 2018 at 12:25 PM Denys Dmytriyenko <denys@ti.com> wrote:
> > > > > > 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
> > > > >
> > > > > OK, do you want to submit a patch for that or should I do one and just
> > > > > Suggested-by you?  Thanks!
> > > >
> > > >Yes, that's right.
> > > > This would not be acceptable change since it changes how we build gcc
> > > > itself secondly it does not happen for master uboot
> > > >
> > > > However if this works then we need to understand why it increas e the size
> > >
> > > Even if this change is not acceptable upstream, I would prefer it locally in
> > > meta-ti recipe, instead of disabling more features to free up 5-6KB in SPL.
> >
> > this is a distro level change. meta-ti is not appropriate place to decide that
>
> Are we talking about passing fno-pie and fno-stack-protector to U-boot build
> that you suggested above? That is what I'm referring here. It can be BBB
> specific patch. That is until we figure out why it grows code so much...
>
oh I confused it with GCCPIE

> --
> Denys

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

[Khem Raj]

On Tue, Oct 16, 2018 at 11:29 AM Denys Dmytriyenko <denys@ti.com> 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@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@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@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-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.

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 11:50:36AM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 11:29 AM Denys Dmytriyenko <denys@ti.com> 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@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@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@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-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...

-- 
Denys

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

[Khem Raj]

On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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.

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

[Khem Raj]

On Tue, Oct 16, 2018 at 12:20 PM Khem Raj <raj.khem@gmail.com> wrote:
>
> On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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.

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 02:19:36PM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 12:20 PM Khem Raj <raj.khem@gmail.com> wrote:
> >
> > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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...

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

[Denys Dmytriyenko]

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 <raj.khem@gmail.com> wrote:
> > >
> > > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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.

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

[Khem Raj]

On Tue, Oct 16, 2018 at 5:37 PM Denys Dmytriyenko <denys@ti.com> 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 <raj.khem@gmail.com> wrote:
> > > >
> > > > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 06:42:10PM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 5:37 PM Denys Dmytriyenko <denys@ti.com> 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 <raj.khem@gmail.com> wrote:
> > > > >
> > > > > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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

Neither seem to help.

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

[Denys Dmytriyenko]

On Tue, Oct 16, 2018 at 02:19:36PM -0700, Khem Raj wrote:
> On Tue, Oct 16, 2018 at 12:20 PM Khem Raj <raj.khem@gmail.com> wrote:
> >
> > On Tue, Oct 16, 2018 at 12:00 PM Denys Dmytriyenko <denys@ti.com> 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 <denys@ti.com> 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@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@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@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-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.

I also tried adding -ffile-prefix-map locally and it only shaved off less than 
500 bytes. Still wondering what those extra 5KB of code are...

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

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@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@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@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-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.

Yes, we enforce an ISA in U-Boot, depending on how things are configured
and have been doing thumb2 for a long time on these targets.  But, if we
have some issues here, I'd really like to root cause them.  I'm honestly
surprised the security flags are even being passed, but I guess they end
up put into TOOLCHAIN_OPTIONS not CFLAGS directly?  And what/when/how do
we reliably get an overflow?  Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]