On Mon, Nov 14, 2016 at 9:32 PM, Jose Luis Zabalza <jlz.3008@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
