[U-Boot] Testing report for i.MX51 using Linaro/Ubuntu gcc 4.6.3 (from Precise repositories), libgcc, etc.
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?
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
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
participants (3)
-
Matt Sealey -
Rob Herring -
Wolfgang Denk