Compiler issues

Compiler issues

[Jose Luis Zabalza]

Hello everybody

I continue to have problems with memory size but I suspect they may be
due to a compiler issue.

It is possible?

I am using this compiler (from ubuntu package on X86_64)


$ arm-linux-gnueabi-gcc -v

Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-12ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.7.3
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-gnu-unique-object
--disable-libmudflap --disable-libitm --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog
--enable-cloog-backend=ppl --disable-cloog-version-check
--disable-ppl-version-check --enable-multiarch --enable-multilib
--disable-sjlj-exceptions --with-arch=armv5t --with-float=soft
--disable-werror --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=arm-linux-gnueabi
--program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1)


Thanks in advanced

-- 

jlz.3008  a t  gmail.com
Linux Counter 172551
https://linuxcounter.net/cert/172551.png

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Compiler issues

[Jose Luis Zabalza]

Thanks for your reply, Holger.

I am sorry. I have to apologize for no mentioning that this thread is
the continuation of "Re: Configure RAM size on iMX53 board".

I will summarize the situation. I have a iMX53 custom board with two
versions, 512MB (only CS0) and 1GB (CS0 and CS1) RAM. Both versions
are running with same old uboot binary because uboot don't access to
high memory address. I write code for support Barebox on 1GB version
successfully but hangs on 512MB version.  No messages are displayed on
console.

Sascha recomends me don't configure CS1 on DCD table and use
barebox_arm_entry() function instead of imx53_barebox_entry() but it
don't work.

So, the first step was  find where the code hangs.

I activated a GPIO on DCD table and deactivate on Barebox code to know
if a function is executed.

==========<cut>===========
wm 32 0x53F84004 0x00000008  // Set GPIO as output
wm 32 0x53F84000 0x00000008  // Activate GPIO

...

*((unsigned *)0x53F84000)=0; // Deactivate GPIO
==========<cut>===========

With the trial and error method, I found the execution lack on
initcall secuence. Specifically don't reach myboard_initcall()

==========<cut>===========
static int myboard_init(void)
{
    *((unsigned *)0x53F84000)=0;

    imx_esdctl_disable();

        arm_add_mem_device("ram0", MX53_CSD0_BASE_ADDR, SZ_512M);

        return 0;
}
core_initcall(myboard_init);
==========<cut>===========

So I changed core_initcall() to pure_initcall() for early
myboard_init() execution and It was good but Barebox hangs on another
initcall function.

Next trial and error session I found imx_gpio_add() was not reached,
so I suspect it was a compiler problem or a timing problem. I
discarded the timing problem because It was very repetitive.

I changed -Os option with -O0 on Makefile. Now imx_gpio_add() are
executed Ok but net_init() hangs.

The final firework:

==========<cut barebox/net/net.c>===========
//
// this code don't deactivate the GPIO
//
static int net_init(void)
{
    int i;

    for (i = 0; i < PKTBUFSRX; i++)
      NetRxPackets[i] = net_alloc_packet();

    *((unsigned *)0x53F84000)=0;

==========<cut>===========
//
// This code YES. It deactivate the GPIO
//
static int net_init(void)
{
  volatile int i;

    for (i = 0; i < PKTBUFSRX; i++)
    {
      if(i > 10)
      {
      // this code is not executed because PKTBUFSRX is 4
      }

      NetRxPackets[i] = net_alloc_packet();
    }

    *((unsigned *)0x53F84000)=0;
==========<cut>===========

Now, the code hangs on other unknow initcall function but I think
that's not the problem.

Some idea?
Some dark compiler flag to de/activate ?

Thanks in advanced.

2016-11-14 10:12 GMT+01:00 Holger Schurig <holgerschurig@gmail.com>:
> Jose Luis Zabalza <jlz.3008@gmail.com> writes:
>
>> I continue to have problems with memory size but I suspect they may be
>> due to a compiler issue.
>
> I doubt it ... but what made you thinking this?
>
> (BTW, I'm using arm-linux-gnueabihf-gcc 4.9.2-10 from Debian for
> Barebox, Kernel and some userspace stuff)
>
>
> You should be more specific, e.g. what architecture are you using?
> How's your .config file?  Maybe you simply deselect things there?
>
> Did you know that you can run "nm --size-sort barebox | tail" to find out what
> takes the most space?
>
>
> Holger



-- 

José Luis Zabalza
jlz.3008  a t  gmail.com
Linux Counter 172551
https://linuxcounter.net/cert/172551.png

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: Compiler issues

[Andrey Smirnov]

On Mon, Nov 14, 2016 at 9:32 PM, Jose Luis Zabalza <jlz.3008@gmail.com> wrote:
> Thanks for your reply, Holger.
>
> I am sorry. I have to apologize for no mentioning that this thread is
> the continuation of "Re: Configure RAM size on iMX53 board".
>
> I will summarize the situation. I have a iMX53 custom board with two
> versions, 512MB (only CS0) and 1GB (CS0 and CS1) RAM. Both versions
> are running with same old uboot binary because uboot don't access to
> high memory address. I write code for support Barebox on 1GB version
> successfully but hangs on 512MB version.  No messages are displayed on
> console.
>
> Sascha recomends me don't configure CS1 on DCD table and use
> barebox_arm_entry() function instead of imx53_barebox_entry() but it
> don't work.
>
> So, the first step was  find where the code hangs.
>
> I activated a GPIO on DCD table and deactivate on Barebox code to know
> if a function is executed.
>
> ==========<cut>===========
> wm 32 0x53F84004 0x00000008  // Set GPIO as output
> wm 32 0x53F84000 0x00000008  // Activate GPIO
>
> ...
>
> *((unsigned *)0x53F84000)=0; // Deactivate GPIO
> ==========<cut>===========
>
> With the trial and error method, I found the execution lack on
> initcall secuence. Specifically don't reach myboard_initcall()
>
> ==========<cut>===========
> static int myboard_init(void)
> {
>     *((unsigned *)0x53F84000)=0;
>
>     imx_esdctl_disable();
>
>         arm_add_mem_device("ram0", MX53_CSD0_BASE_ADDR, SZ_512M);
>
>         return 0;
> }
> core_initcall(myboard_init);
> ==========<cut>===========
>
> So I changed core_initcall() to pure_initcall() for early
> myboard_init() execution and It was good but Barebox hangs on another
> initcall function.
>
> Next trial and error session I found imx_gpio_add() was not reached,
> so I suspect it was a compiler problem or a timing problem. I
> discarded the timing problem because It was very repetitive.
>
> I changed -Os option with -O0 on Makefile. Now imx_gpio_add() are
> executed Ok but net_init() hangs.
>
> The final firework:
>
> ==========<cut barebox/net/net.c>===========
> //
> // this code don't deactivate the GPIO
> //
> static int net_init(void)
> {
>     int i;
>
>     for (i = 0; i < PKTBUFSRX; i++)
>       NetRxPackets[i] = net_alloc_packet();
>
>     *((unsigned *)0x53F84000)=0;
>
> ==========<cut>===========
> //
> // This code YES. It deactivate the GPIO
> //
> static int net_init(void)
> {
>   volatile int i;
>
>     for (i = 0; i < PKTBUFSRX; i++)
>     {
>       if(i > 10)
>       {
>       // this code is not executed because PKTBUFSRX is 4
>       }
>
>       NetRxPackets[i] = net_alloc_packet();
>     }
>
>     *((unsigned *)0x53F84000)=0;
> ==========<cut>===========
>
> Now, the code hangs on other unknow initcall function but I think
> that's not the problem.
>
> Some idea?
> Some dark compiler flag to de/activate ?

That explanation is not very simple so it is unlikely to be true. If I
were to guess I'd say you are still having problems with RAM
boundaries calculation because what you describe reminds me of the
behavior I've observed many times when Barebox gets relocated such
that part of the image is placed into area that does not correspond to
RAM, so that some of the code is good and some of it is bad.

I would recommend configuring DEBUG_LL, instrumenting
barebox_arm_entry from entry.c to display membase and memsize and
making sure they fall within a valid region.

Hope this helps,
Andrey Smirnov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox