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 at gmail.com>:
> Jose Luis Zabalza <jlz.3008 at 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