[U-Boot] Initializing global_data on SuperH before board_init_f() ?

[Lokesh Vutla]

Hi Thomas,

On Wednesday 16 August 2017 02:37 AM, Thomas Petazzoni wrote:
> Hello,
> 
> As you probably noticed with the few patches I sent late July, I am
> porting U-Boot to an old SH7786 platform. As part of this effort, I
> stumbled across a bug: the global_data structure is not initialized to
> zero by the SuperH architecture code before calling board_init_f().
> 
> The SuperH architecture code defines the global data in
> arch/sh/lib/start.S:
> 
>         mov.l   ._gd_init, r13          /* global data */
> [...]
>         mov.l   ._sh_generic_init, r0
>         jsr     @r0
> [...]
> ._gd_init:              .long   (_start - GENERATED_GBL_DATA_SIZE)
> ._sh_generic_init:      .long   board_init_f
> 
> So basically, it makes r13 points to the global data (which is expected
> on this architecture), and then calls board_init_f().
> 
> Hence, we enter board_init_f() with global_data uninitialized, which
> have caused me quite some troubles, as I was seeing semi-random
> behavior: in various places, we test if a pointer in global_data is
> NULL or not to decide to do something (or not). This obviously goes
> really bad when global_data contains garbage.
> 
> Should we put global_data within the .bss section, so that it gets
> zero-initialized automatically? Should we zero-initialize it explicitly?

I am not sure how SuperH allocates the space for global data but
typically the following two function takes care of allocating and
zeroing global data(at least for arm):

In file common/init/board_init.c
board_init_f_alloc_reserve()
board_init_f_init_reserve()

May be, using these two functions might solve your problem.

Thanks and regards,
Lokesh

> 
> I've currently worked-around the problem by adding a memset() to zero
> of the global_data at the beginning of board_init_f(), but I'd prefer
> to find an upstreamable fix.
> 
> Thanks!
> 
> Thomas Petazzoni
>