[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[Matt Sealey]

Marek Vasut insists I report this to the list, so here goes;

Compiling a U-Boot for i.MX51 here (for the Efika MX) basically
doesn't operate well. Among other things, we got data aborts in
several places, most annoyingly sometime after boot_relocate_fdt. This
was using a 64-bit Ubuntu Precise Pangolin (12.04) installation, the
standard "arm-linux-gnueabi-gcc-4.6" (4.6.3-1ubuntu5) compiler and
other toolchain components (no modifications made).

Using USE_PRIVATE_LIBGCC=yes solved the issues, as did changing to the
gcc 4.4.7 (4.4.7-1ubuntu2) and using either private libgcc or the one
provided by the toolchain.

This is not the first problem we've ever had with the Linaro gcc
toolchain, especially not with 4.6. So far, reverting to building
using gcc 4.4.7 has solved all the problems, and we're using
USE_PRIVATE_LIBGCC by default now anyway because I don't see the point
in using the one provided with the toolchain if it is such a huge
unknown and U-Boot provides a compatible feature anyway.

I'm not sure what anyone on the list is going to make of this or if it
influences some design decisions anywhere else in U-Boot, just that I
was nagged incessantly to "report my findings" - we all knew the
Linaro compiler generally sucks already, though, right?

-- 
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.

[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[Wolfgang Denk]

Dear Matt,

In message <CAKGA1b=KecRhXzJWor6xRTY2p6A1ukofoPoHm-1DwQqRw8aCOQ@mail.gmail.com> you wrote:
> Marek Vasut insists I report this to the list, so here goes;

Indeed such problem reports are valuable information, so thanks for
the message.

> This is not the first problem we've ever had with the Linaro gcc
> toolchain, especially not with 4.6. So far, reverting to building
> using gcc 4.4.7 has solved all the problems, and we're using

Did you report this to Linaro as well?  Because this is where the
people sit that should fix such issues.  We can do nothing here -
except to avoid such broken tool chains.

> USE_PRIVATE_LIBGCC by default now anyway because I don't see the point
> in using the one provided with the toolchain if it is such a huge
> unknown and U-Boot provides a compatible feature anyway.

Please do NOT do this by default.  USE_PRIVATE_LIBGCC is meant as a
workaround for known-to-be-broken tool chains for which no alternative
exists.  In your case you hcan chose a working tool chain, so please
rather do this.

By always using USE_PRIVATE_LIBGCC you just close your eyes for
potential tool chain problems - why exactly would you trust in a tool
chain where such a simple and fundamental piece of code asl ibgcc is
broken?

> I'm not sure what anyone on the list is going to make of this or if it
> influences some design decisions anywhere else in U-Boot, just that I
> was nagged incessantly to "report my findings" - we all knew the
> Linaro compiler generally sucks already, though, right?

Thanks for the report and the clear words; maybe you could send a
similar report or a link to this posting to Linux, for example to
Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org> ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I'm not a god, I was misquoted."                 - Lister, Red Dwarf

[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[Rob Herring]

On 08/02/2012 12:49 PM, Matt Sealey wrote:
> Marek Vasut insists I report this to the list, so here goes;
> 
> Compiling a U-Boot for i.MX51 here (for the Efika MX) basically
> doesn't operate well. Among other things, we got data aborts in
> several places, most annoyingly sometime after boot_relocate_fdt. This
> was using a 64-bit Ubuntu Precise Pangolin (12.04) installation, the
> standard "arm-linux-gnueabi-gcc-4.6" (4.6.3-1ubuntu5) compiler and
> other toolchain components (no modifications made).
> 
> Using USE_PRIVATE_LIBGCC=yes solved the issues, as did changing to the
> gcc 4.4.7 (4.4.7-1ubuntu2) and using either private libgcc or the one
> provided by the toolchain.
> 
> This is not the first problem we've ever had with the Linaro gcc
> toolchain, especially not with 4.6. So far, reverting to building
> using gcc 4.4.7 has solved all the problems, and we're using
> USE_PRIVATE_LIBGCC by default now anyway because I don't see the point
> in using the one provided with the toolchain if it is such a huge
> unknown and U-Boot provides a compatible feature anyway.
> 
> I'm not sure what anyone on the list is going to make of this or if it
> influences some design decisions anywhere else in U-Boot, just that I
> was nagged incessantly to "report my findings" - we all knew the
> Linaro compiler generally sucks already, though, right?

Do you have unaligned-accesses disabled? This version of the compiler
and gcc 4.7 or later will generate unaligned accesses which u-boot does
not enable the h/w for. There was a patch recently to address this.

Rob

[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.

[Michael Hope]

Hi Matt.  Let me know if you find a fault in the compiler and we'll
fix it.  A common problem is bare metal projects turning on strict
alignment fault checking in the hardware (bit 1 of SCTLR on the A9)
which causes a data fault on unaligned access.  See [1] for more.

You might try our pre-built binaries[2].  The Linux version runs on
anything RHEL 5 or later and includes both a ARMv7 and a very
compatible ARMv4T runtime.

-- Michael
[1] http://seabright.co.nz/2012/06/11/kernel-not-booting-with-linaro-gcc/
[2] https://launchpad.net/linaro-toolchain-binaries